After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 564431 - Copy/Move operations should be queued under some circunstances.
Copy/Move operations should be queued under some circunstances.
Status: RESOLVED DUPLICATE of bug 124783
Product: nautilus
Classification: Core
Component: File and Folder Operations
2.24.x
Other All
: Normal enhancement
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-12-13 23:43 UTC by sromero
Modified: 2010-04-27 13:11 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description sromero 2008-12-13 23:43:35 UTC
Hi,

 I think that a very nice enhancement could be done to copy/move operations when using the file explorer. When a copy/move operation is in progress, new copy/move operations should be QUEUED instead of executed in some circunstances, such as:

- Copy/Move source is the same as the source in any copy/move operation currently being executed.
- Copy/Move destination is the same as the source in any copy/move operation currently being executed.

 Think in those situations:

- You're copying a big file from a DVDROM (call it "copy source 1"). You continue browsing the DVD, and you want to copy more big files. You select another file and drag it to the destination. Then, as the "copy 1" is still in progress, the CDROM starts to "spin" moving from "copy source 1" to "copy source 2". Both copy operations slow down due to CD beam moving between different disk positions.

- You're copying big files to a local HDD drive and you plan to leave the computer "copying" while you do some extra things away from the computer. All files are not in the same source folder, so you can't just "select" all simultaneously. You drag & drop the first one (which starts copying) and you move to another folder to drag & drop another file. Then, the disk header of the local drive you're copying the files to starts moving between the 2 destination sectors in the drive. If destination drive uses FAT/FAT32 fs, filesystem can get fragmented. And the time needed to copy both files is larger that the sum of the times needed to copy both files separately (due to disk header movement).

 The ideal when using the GUI of a file explorer for all those situations should be:

- First file operation starts inmediately (source1 -> dest1) .

- When you drag&drop the second, third, ... files, if source == source1 or dest == dest1, the copy/move operation would be queued and delayed until the first operation ends. If source and destination are different then the copy/move operation can be done simultaneously to the current active operation.

- Queued operations would appear in the screen just like any active operation, in a "copy" dialog similar to current copy dialogs, but status bar would show a text like " Queued ", and would include a button to unqueue and execute them if the user wants to. Like the current "File operation in progress" dialog for nautilus, where extra copies are added below the existing ones, in this case "Queued" copies would be added, plus the current "Cancel" button and an extra "Dequeue/Start copy" button.

- All this behaviour could be configured as an option in "Preferences" (Something like [X] "Queue I/O operations using the same source or destination than active operations").

 I do really think that the above behaviour would be very interesting and would solve lots of slowdowns and problems when copy from/to CD, DVD, flash drives, USB disks or even local harddrives.

 Thanks a lot :)
Comment 1 sromero 2008-12-14 10:17:27 UTC
 Oops, typo error:

> - Copy/Move destination is the same as the source in any copy/move operation
> currently being executed.

- Copy/Move destination is the same as the *DESTINATION* in any copy/move operation currently being executed.

 Sorry for the mistake.
Comment 2 jespera 2008-12-15 16:02:59 UTC
I'm sorry for posting in this enhancement report just to say: that sounds like a very useful thing. I wish I had time to (help) implement that!
Comment 3 Alexander Larsson 2008-12-16 09:11:49 UTC
Sounds nice. Could also be nice to have a "queue" button in the transfer dialog so that you can manually enable it for a transfer (if you know more than the computer about what is happening).
Comment 4 Matthew Paul Thomas (mpt) 2009-01-13 21:12:10 UTC
A possible presentation of paused operations, and a method for manual queuing of operations, is presented in <http://live.gnome.org/Nautilus/ProgressWindow>. Automatic queueing is not covered but would be quite compatible with that design.

It would make sense for automatic queueing to be a preference only if it was helpful overall for some people but unhelpful overall for others, and if many of the people who would be better served by the non-default setting were willing and able to change it. I doubt either of those are true. Either automatic queueing will help most people most of the time, or it won't.
Comment 5 Przemysław Kulczycki 2009-05-19 19:43:43 UTC
Another mockup:
https://wiki.ubuntu.com/copy_queing
Though its older than the previous one
Comment 6 Cosimo Cecchi 2010-04-27 12:45:32 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 124783 ***