https://bugs.kde.org/show_bug.cgi?id=161017
John <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #29 from John <[email protected]> --- I've been waiting for this for quite a long time too as I'm tired of having to always check or wait for a transfer to finish so I can start another one. It would be great if I could just copy or move lots of folders and files one after another and just the first one to be started and the rest to be queued. There are still 10 or more years to wait until more people will have only SSD-based external drives that will allow parallel at good speeds. And with what AI is doing to the prices of RAM and storage, we might need to wait even more, so the queuing of disk operations is even more important to have. I assume it can even be implemented in steps, like: 1. If a transfer (copy or move) to destination X folder is already ongoing (in progress) the enqueue the next one and the next one and so on, if their target is the same destination X folder. 2. If a transfer (copy or move) to destination X folder, on drive Y is already ongoing (in progress) the enqueue the next one and the next one and so on, if their target is the same drive Y. I think case 2 is harder to implement as the detection of the drive could be not easy when the drive is encrypted, mounted, symlinked, BTRFS subvolume, etc. But at the moment, if case 2 is too daunting to tackle from the beginning, maybe we can can have case 1 implemented with the same destination folder. -- You are receiving this mail because: You are watching all bug changes.
