2

I was trying to move some files into a folder (E: to E: so i'm pretty sure it's moving and not copying) but it's taking like minutes just to move some 60k files. I was under the impression that file moving is supposed to be really fast, so I was curious what does the computer have to do to move some files into a folder?

(I'm using Windows Vista Home Premium Sp2, but actually I was hoping to target the question in a broader way)

  • It's a known issue with Vista... encrypted.google.com/… – Joe Internet Sep 1 '11 at 2:20
  • 4
    Actually that was a problem early on in Vista, it was cured with SP1, something else is wrong, run a chkdsk /r ..on the hard drive. – Moab Sep 1 '11 at 2:32
  • Firstly, doing something 1,000 times per second (60k / 60s) IS fast. Secondly, loose the GUI if you want it to go faster. Third, as others have pointed out, moving just the directory entry is going to be nearly instant while moving the individual files is going to take much longer. – krowe Oct 11 '14 at 18:25
  • @krowe, It's relative and depends on what you are doing. Drawing 1000 pixels per second is extremely slow. – Pacerier Oct 12 '14 at 5:49
3

Even though you are just moving the files to a folder that is on the same disk, the filesystem still has to do a bit of work to move the files. The Master File Table (MFT) has to be updated to reflect the new location of the files, and the filesystem journal also has to be updated to allow changes to be rolled back in case the move is interrupted by a power outage, etc.

I'm not sure how to calculate exactly how many different things that the filesystem has to do, but we can assume that it will have to do at least 60k changes to the MFT. This many changes entails a lot of small reads and writes, which hard drives are not very fast at.

| improve this answer | |
  • well i believe it took like 3 minutes, so do you mean to say every second it can only handle like 333 changes? – Pacerier Sep 1 '11 at 3:37
  • Well, my estimation of 60k changes was very optimistic. I haven't been able to find a good source for this, but from memory I think that there are approximately 3 operations necessary for each file (making for ~180k total). (1) Write rename metadata to journal, (2) do actual rename operation, and (3) write that rename was successful to journal. This is a lot of work to do, and filesystems are very conservative in doing these things. So a number more like 1000 changes per second seems reasonable. Which isn't that bad given the number of operations that are necessary. – cmorse Sep 1 '11 at 4:50
  • I almost forgot. Unless it has already been cached, the filesystem also has to compile a list of all the files and folders the need to be moved. – cmorse Sep 1 '11 at 4:54
  • to confirm, you mean that moving 1000 1KB files is like 1000x slower than moving a 1GB file because afterall it's the number of files that matter and the size is arbitrary? – Pacerier Sep 1 '11 at 5:19
  • Yes, that's what I was getting at. – cmorse Sep 1 '11 at 6:15
1

Warning: Late Answer Below

  1. 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).

  2. 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:

  1. does file operations in chunks (more reading and writing),
  2. 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.

| improve this answer | |
  • Are you sure about the W: deletes (overwrites with random values) the original file ? – Hennes Aug 30 '16 at 13:29
  • Some systems may overwrite with 0's... But it overwrites at least a part of the file to delete it. – sbrm1 Aug 31 '16 at 6:22
  • @Hennes Edited answer. – sbrm1 Aug 31 '16 at 6:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.