Avoid parallel copy operations

[warpkanal]

Would love to have the option to either explicitly queue (copy) operations or simply have a global option to e.g. only process 1 (copy) operation at a time and enqueue all other.
Why: when copying big files (esp. on non-flash storage), doing this in parallel slows down the operations greatly (and the total time taken will be much bigger than if the operations would have been done one after the other)

[JayB]

That's right. Noticed this too. But Finder has the same problem with copy on rotating disks. On SSDs this shouldn't really be a problem; afaik SSDs can do multiple write operations simultaneously, different from legacy disks which can only write one thing at a time. (But I might be wrong on this.)

[warpkanal]

You're right, on SSDs the problem is not that apparent (as there is no reading head that must be re-positioned over and over), while on spindles it's very noticeable.
I've seen two solutions in filemanagers to this: a) allow to explicitly queue operations (e.g. in good old TotalCommander(Win) or Commander One (Mac)) or b) have a setting to restrict parallel operations to a given number where you can enter '1' to effectively disable parallel operations (e.g. in ForkLift or Crax)
(while I prefer option b) instead of having every time to explicitly queue a copy operation)

[JayB]

I also prefer option b, but there should also be the value 0 for "no restrictions", ergo:

0: no restrictions (as many simultaneous operations as possible)
1: queue (1 operation at a time)
2–n: restrict to 2–n simultaneous operations at a time

[warpkanal]

makes sense to me, hopefully also to mike

[mike]

I agree with simple approach of limiting amount of concurrent operations per-window, with ability to tune it in Preferences.

Personally I've been thinking about some more sophisticated system, which will decide if operation can be concurrent or not depending on it's source and target, their media types, operation type etc etc blah-blah. Ah, also chaining of operations depending on that info.
Every time it has ended up with some monstrous design, sufficient to write another PhD thesis
So every time I've decided to leave this untouched, since such intelligent system would take huge amount of time to implement and debug.

[swoop]

Since simple approach seems to be viable, I'm moving my proposal from http://magnumbytes.com/forum/viewtopic.php?f=6&t=223.

---
One feature that is a must (and present in TC on Win and other Commanders on macOS) is file queue.

I see that NC has file operation list. That is an amazing start and a feature. I'd like to suggest the next steps.
- When starting Copy/Move (F5/F6) option to queue operation
- Setting to start file operations queued (executed sequentially) always
- Include delete in file operations (deleting can be queued and will be executed after successful previous file operations)

There are many additional use cases, but the above will be covering the proverbial 80%. Cheers!