nautilus should copy/move smarter (queue files)

nautilus uses gvfs as a backend, re assigning.

could you send it upstream at bugzilla.gnome.org since you're interested on the feature? otherwise this bug can be closed if there's no action on it for a few weeks thanks.

Before entering, I did a search. Here is the same problem:

http://bugzilla.gnome.org/show_bug.cgi?id=413748

I truly hope this gets fixed!

thanks, linking the report.

The user basically suggest that copying you small text file which takes 5 seconds will be blocked for an hour if you copy a DVD image, that seems to not be a so trivial binary choice and probably not an hundredpapercut either

No he only says that if both are being copied simultaneously (to the same volume/device), the total time needed is much more than when they copied after each other. Seems pretty trivial to wait for one file to finish copying before starting the next.

So you wait on a DVD to be copied to copy a small image file next, or you need to start having logic on what is copied etc and that's far from being trivial

Yes, you wait. But you wait shorter in total than when they are copied simultaneously, like happens now. And the usual case would be like described in the original report: dragging a collection of photos somewhere, and the some more photos and suddenly the copying becomes really slow. In this case it saves lots of time.

Intelligent file copy optimization is a feature, not a trivial usability fix; this is a great idea, but not a paper cut.

For me it would be enough to have a pause-Button for every item in the copy dialog. Then I could decide on my own which batch I want to prefer.

Reassigning to match the product of the upstream bug.

Hello, I would like to add 2 cents to this thread:
1) The remark made by "David Siegel" is incorrect.
The request is *not* to implement: <<Intelligent file copy optimization>>, but simply to queue the files to copy so that they're copied sequentially.
If I select 2 files and drag them across two "locations", these two files will be copied sequentially.
If I drag the two files one after the other, the copy will occur concurrently - as a result, the time that it takes to copy the two files will be significantly longer. This should be changed so that the files are copied sequentially even in this case.

2) The behavior of Nautilus is the same as Windows Explorer. There are several tools in Windows (e.g.: TotalCommander) which implement this auto queuing. I mention this because this proves that the implementation is certainly possible.

@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.

I fully agree that Nautilus could be smarter during file transfer management, with a smarter queuing and priority management logic. David didn't claim that it was impossible (and neither do I), but it's not trivial to implement, and certainly not a paper cut.

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

@Darshaka Pathirana:
How can you "full ACK" a statement that you oppose in your very next sentence? Walter proposed to ALWAYS queue files, which is definitely not a good idea. "Do something more than just always process in parallel or always queue", be it to ask the user, have some smart logic or a mixture of the two, is what I wrote about, and is in any case not a trivial change.

On 05/13/2010 02:58 PM, Holger Berndt wrote:
> @Darshaka Pathirana:
> How can you "full ACK" a statement that you oppose in your very next
> sentence? Walter proposed to ALWAYS queue files, which is definitely
> not a good idea. "Do something more than just always process in
> parallel or always queue", be it to ask the user, have some smart
> logic or a mixture of the two, is what I wrote about, and is in any
> case not a trivial change.

Ok, sorry. Full ACK went to the statement "The request is *not* to
implement: <<Intelligent file copy optimization>>"..

I did'n state that the change to a queueing behavoir would be trivial.
But I fully agree with the fact that there are some pieces of software
which implement the needed feature... e.g. TotalCommand let's you
choose wheter the file should be copied immediately or be queued.

So again: we (at least me and Walter) don't need the "intelligence" on
software side instead just let the user choose (e.g a seperate "add to
copy-queue" option).

Regards,
 - Darsha

/me wants a port of TeraCopy in Ubuntu.

I will settle with a pause function in Nautilus copy too. Then at least I can queue the copy's myself.

It does not have to be complicated actually. I think a workable rule is to queue local files and parallel queue any network file systems. The decision should really come from the gvfs-backends daemon on case by case basis.

Well actually, I have no idea how hard that is to implement, so maybe it is indeed hard.

GIO/Gvfs/Glib library (take your pick) could provide the interface to queue files that the gvfs-backends daemon instantiates and configures. Alexander Larsson might know the best design, as he seems to have written most of the gvfs anyways.

my 2 cents, what about this?

Every copy operation initiated (after the first one) starts in a paused state (its queued), so you see the list of copying operations (or pending ones), but you put a play/pause button next to each operation, so in the standard case everything gets queued, but you press play in the file(s) that you want to want to do concurrently and its done.

Theres no checking for destination, size or any other "intelligent" feature, just autoqueue with the possibility to force parallel copying/moving at the users discretion.

i think we wont have neither of the 2 problems on this case, later it would be cool to arrange the order inside the queue but its out of this scope i guess.

upstream bug marked as duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=124783

Same demand on XFCE with Thunar : https://bugzilla.xfce.org/show_bug.cgi?id=12123