Add a facility or configuration option to Dolphin file manager to queue up sequential copy or move jobs either as a general dolphin option or on any single file operation. As an example, say I want to copy a 100GB file from one drive to another. This is a long process, which we will call Job1. Whilst this file operation is in progress I should be able to queue up another long file copy that will commence after Job1 is completed. The reasoning behind this is that I would want these jobs to run synchronously to maximise disk throughput and minimise disk thrashing. I might also want to run a third much shorter job and the icing on the cake would be if I were able to pause each batch job in progress and move job priorities.
I would love to see this happen too!!!! It would just make KDE fenominal and way ahead anything any other OS can offer. Is there any way to vote this up?
*** Bug 325611 has been marked as a duplicate of this bug. ***
Seems like one could almost always guess intelligent defaults for a copy/move: * if you're moving on the same device (ie. renaming) or creating a symlink, just do it * if less than 10MiB is involved, just do it (maybe 100MiB?) * otherwise, if there is an operation in progress using either the source or destination device, append to that (ie. enqueue) It seems to be an exceedingly rare situation where one would reasonably want to transfer two large files to/from the same physical device simultaneously? Even an SSD is faster for sequential transfer... Beyond local filesystems it could go either way and manual queuing might be a safer default---perhaps you have kioslaves for several slow network sources. Still, simultaneous copying from disparate network links is really quite an edge case.
It's not a rare occurance for me. If I try to transfer too many streams to a file server after the 3rd stream they begin to timeout over a wireless connection. Plus if you are doing to a drive, I would assume it would help with the access times of those files instead of having all that fragmentation.
*** This bug has been confirmed by popular vote. ***
So happy to see that this is confirmed : this is extremely useful when you have a lot of tranfers to do, from and to a lot of different folders !!! On windows, this was covered by supercopier/ultracopier or terracopy back in the days. You can just do all the transfers like maniac and in stead of stupidly doing all of them at the same time, this feature can queue up or not. here's a quick list of supercopier's features - interactive transfers list : can be reordered, moved into a new simulteneous transfert or back into another serialized transfers list - pause / slow down / auto-resume / cancel transfers - automatic behavior to serialize / parallelize transfers. The user should be able to configure what is considered as the "same source" and what is not so it can propose the correct method. Example of a situation where it seems impossible to detect without user's configuration: 2 pools of drives on a nas mounted on your laptop : you can have 2 mounts on the same 1rst pool (i.e. 1-documents and 2-pictures) and 1 mount the other (i.e. 3-medias) to approach the "auto- resume" feature of supercopier, to merge a folder with another (without having to overwrite everything) on linux I have to use a command line : `rsync -avhP --progress --remove-source-files /source/directories/ /target/directory/` and it's not perfect : as I have to manually delete the source folders, only the files have moved