| Summary: | Intelligently sequential copy/move jobs | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | mcnaz <mcnazar> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | barcenas.francisco, bugseforuns, geoffm, kdelibs-bugs, nate, nikolakocicbz, rom1dep, skomorokh, stievenard.david, tom-kde.bugs |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
mcnaz
2012-03-15 21:02:25 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? *** 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 |