Comment 17 for bug 306630

On 05/13/2010 01:56 PM, Holger Berndt wrote:
> @Walter_I
> In my oppinion, David Siegel's remark is absolutely correct, and you
> are wrong. It's not as simple as you put it. Whether or not copying
> in parallel takes significantly longer depends on a number of
> factors (is target and/or source on a slow network connection, am I
> copying from a CD or a SSD etc). Also, sometimes I want parallel
> copies even if they might be slower in total, to increase
> reactivity.
>
> Consider the following (exaggerated) use case: I am copying a DVD image
> to a remote host on a slow link. ETA: 17 hours. Now, 5 hours after I
> initiated the file transfer, I want to copy a 12 kB ini file from /etc/
> to /srv/foo. In your proposed solution, I would have to wait 12 hours
> for it to arrive. You can't seriously think that this would be an
> improvement.

My full ACK goes to Walter: so the possible solution would be to let
the user choose wheter he wants to queue or not. I definitely do *not*
expect some kind of "intelligent" copy process... (at least not in the
first stage of improving the copy/move process).

JM2C && Regards,
 - Darsha