1

I noticed that one of my drives was full after moving some files onto it:

enter image description here

I thought it unlikely that copying files of random sizes would result in exactly filling the available space, so I became suspicious.

I then dragged a file that was 1.57 MB off the drive and onto my desktop (via shift+drag). The drive's free space then said 1.52 MB, which didn't make sense. I then clicked "Undo Move" and it would not move the file back, claiming there was not enough free space.

Can anyone make sense of this? There is nothing else being written to the drive. I'm guessing it has something to do with the internal structure of the drive (e.g. fragmentation [although it says 0% fragmented]), and this is a drive on a virtual machine.

Community
  • 1
Triynko
  • 3,274
  • 7
  • 24
  • 27
  • How did you configure the virtual hdd? Did you configured it to automatically expand or be a fixed size? – Ramhound May 26 '15 at 18:44
  • It's a fixed size on a VM hosting service, which I did not configure. – Triynko May 26 '15 at 18:49
  • In order to determine if something really is using your space as it becomes free, you have to make more then 2MB free, Windows would just use that in generating a text file saying the HDD ran out of space. If you expand the size of the virtual hdd does this still happen? – Ramhound May 26 '15 at 18:53
  • It might be your cluster size. If that is too big small files waste tons of space. Also if there is a Windows OS there the windows swap file could have increased in size and used up all the space. Especially if you starve your VM of RAM. – cybernard May 26 '15 at 23:55
  • I'm not concerned with how/why the drive is filling up. I filled it up. I'm just wondering why I can drag a 1.57MB off the drive, but it only frees 1.52MB and cannot be immediately dragged back onto the drive (e.g. via "undo move" in explorer). – Triynko Jun 04 '15 at 16:46

1 Answers1

0

There are various possibilities why a file occupies more disk space when copied to disk than its actual size is:

  • NTFS compression on the source disk can reduce the actually needed storage there
  • A large cluster size on the destination disk than on the source disk can lead to a higher occupied space on disk
  • NTFS shadow copies (used by Windows System Restore Points) are implemented using a copy-on-write strategy. This means, you have a full hard disk state of a previous date, but only if data is actually written, the previous state of this data is saved and occupies disk space.
  • The internal structures of NTFS like the Master File Table (MFT) might increase when new files are copied.

Use a disk space management tool to find out which folders occupy most of your disk space and which space they actually occupy on your disk. Make sure to run them "As Administrator" so that these tools are able to see the whole content of your disk.

There are two features of my tool TreeSize Professional (fully functional 30 day trial available) which might help in this situation:

Community
  • 1
Joachim Marder
  • 460
  • 2
  • 5
  • I'm not interested in why a file occupies more or less disk space; I understand how NTFS compression allows a file to take up less space than the actual file size, and conversely how a file eating up whole clusters can cause it to take up more space than the file size. I'm just interested in why moving a 1.57MB file off the drive, cannot be immediately moved back onto the drive (e.g. via "undo move"). Moving the 1.57MB file off the drive only frees 1.52MB, which doesn't make sense. I should be able to move a file off a drive, and right back onto that same drive. – Triynko Jun 04 '15 at 16:48
  • We're talking about 0.04MB being left behind by a file when removed. We're talking about 41943 bytes not being reclaimed properly. It just seems ridiculous. – Triynko Jun 04 '15 at 16:59
  • In the year 2015 you should not bother about 40k. But your complaints won't change the fact that the internal structures of NTFS increase with an increasing number of files and folders on the disk, and they never shrink again, at least not without the help of 3rd party tools. This seems a pretty good explanation to me. – Joachim Marder Jun 05 '15 at 07:03