if you comment about how windows is bad i will block you. this is not a joke either. do not piss on my effort to help people solve a practical problem they have.
A thing that's always bugged me is that no OS, as far as I know, has a sensible queueing system for concurrent file copies. Like, if you grab a bunch of files in windows explorer, macos finder, or... who am I kidding, nobody uses a gui file manager on linux, but if you did, and then drug them to another window, it'll copy one file at a time, naturally, because duh.
If you then grab more files, from the same or a different folder, and drag them to the same destination, it will start trying to copy both sets of files in parallel, writing blocks semi-randomly from one file or the other instead of finishing one transfer, then performing the second one. This is bad enough on SSDs but if your destination is a spinning disk it'll absolutely destroy your performance, which is what makes it so absolutely wild that this behavior goes back to the 80s, and yeah, I don't think any OS has actually solved for it.
I finally found a way to fix this in Windows though, leveraging a feature that nobody cares about, which they'll probably remove eventually for no reason: Libraries.
Go into Explorer, turn on libraries in the tree view if need be, add a new one, then select all the folders that contain the files you want. Click on the new library, select all the files you want, and copy/cut/drag to the new folder. Windows will now process the whole transfer one file at a time.
I came up with this because I have 6 SSDs, containing 10TB of files, that I need to copy to a spinning disk across a network. I obviously can't sit there and baby the whole process, so I need to start all the transfers at once, but if I pull files from each SSD separately, it'll take 80 hours as it thrashes the disk heads half to death and reduces the transfer speed to kilobytes. The library solution fixes it; I've been getting a clean 250MB/s all day. Good Luck
