Warning: Late Answer Below
The computer builds a list of all files and folders (recursively) which need to be moved (Unless cached, which is rare for all files due to quite prevalent nested directories).
For each file, the computer:
- R: checks if there are any open handles from other programs to the file,
- R: calculates the size of the file,
- R: checks if the destination exists,
- R: checks if there is enough space in the destination,
- R: checks if a file with the same name is there in the destination,
- R: checks for write permissions to the destination,
- R: reads the file from the source,
- W: writes the file to the destination,
- R: reads file ownership, permissions and ACL information from the source,
- W: writes file ownership, permissions and ACL information to the destination,
- R: reads the file table,
- W: writes the updated file table,
- W: deletes (overwrites with random values or 0's) the original file (or a part of it),
- R: reads the file table again (for the delete),
- W: writes the updated file table again (for the delete).
This puts the figures at 15 operations per file (10 read, 5 write; actually the number of operations are more more), therefore for 60k files there were more than 900k operations, that is 5k operations per second.
Assuming that that both the source and destination were on the same media (almost always removing the possibility of true simultaneous operations), again assumed to be a hard drive (adding a lot of mechanical movement going on), 5k operations (plus background file operations) is quite good.
And the above is for the smallest of all files.
Considering the size of the files, most operating systems:
- does file operations in chunks (more reading and writing),
- tries not to burn out your hard drive by not using it at 100%.
If you call your computer slow after that, try moving physical files and documents (60k of them) ONE-by-ONE.
Sorry for the sarcasm in the last line, I was trying to drive home my point.