Bug 296109 - Add a facility to Dolphin to enable sequential copy/move jobs
Summary: Add a facility to Dolphin to enable sequential copy/move jobs
Status: CONFIRMED
Alias: None
Product: kio
Classification: Unclassified
Component: general (show other bugs)
Version: SVN
Platform: unspecified Linux
: NOR wishlist with 140 votes (vote)
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
: 325611 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-03-15 21:02 UTC by mcnaz
Modified: 2016-01-16 13:15 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mcnaz 2012-03-15 21:02:25 UTC
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.
Comment 1 Frank 2013-05-11 20:04:20 UTC
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?
Comment 2 Christoph Feck 2013-10-04 13:02:22 UTC
*** Bug 325611 has been marked as a duplicate of this bug. ***
Comment 3 skomorokh 2013-10-17 20:13:42 UTC
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.
Comment 4 Frank 2013-10-18 16:01:17 UTC
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.
Comment 5 Tom Mittelstädt 2016-01-16 13:10:22 UTC
*** This bug has been confirmed by popular vote. ***