I am either confused as to how Windows calculates the Size on disk value in the properties of a folder, or it is incorrect.

The cluster size on my drive is 4096 byes.

I've created a folder called size-on-disk-test in which I have 64 direct sub-folders and 362,496 files. Each and every file is a text file 3 bytes in size simply containing the text: aaa.

Given each file should in theory use up a single cluster of 4096 bytes, then I should expect to see the file size on disk to read:

number-of-files * cluster-size362,496 * 4096 = 1,484,783,616 (1.4GB).

Instead it reads: 0:

size on disk properties

The Size is, as expected, exactly 3 bytes multiplied by the number of files.

I then made a note of the free space on my disk at the root level and duplicated the folder (this is not a drive with any activity or programs installed, so it should not be affected by other caching etc. on the disk during the test).

According to the check at root level (i.e. clicking properties on my drive in This PC) after duplicating the folder, my free space was reduced by 589,352,960 bytes.

So what is going on? Why is Windows reporting 0 bytes for the size on disk? Why are my calculations wildly off from the reality?

Additionally, does the length of the file name matter? Shouldn't this be taken into account in an accurate calculation? Perhaps the file name length puts a 4095 byte file into two clusters on a 4096 cluster disk? And surely folders take up some allocation space somewhere?

That's a lot of questions for one "question", but I'm hoping someone can just explain to me how the space is taken up including file names, folders and clusters.

  • 1
    Some of your assumptions about how NTFS works are wrong. For example, if the data is less than 512 bytes, it is stored in the MFT not a new cluster. ntfs.com/ntfs-mft.htm Commented Jul 24, 2017 at 21:28
  • @DavidMarshall the limit is not fixed at 512 bytes. It depends on the metadata size
    – phuclv
    Commented Jul 25, 2017 at 7:16

2 Answers 2


The size on disk value is at best only an approximation, this being particularly true when dealing with a complex file system like NTFS. There are many factors that make this far more complicated than would at first appear. Just a few of these factors:

  • Reparse points
  • Compressed files
  • Hard links
  • Sparse files
  • Alternate data streams
  • File and folder Overhead

Small files may fit entirely in the MFT and will not have any data clusters allocated at all. Exactly what size depends on how much space is available in the files MFT entry. That depends on the length of the file name, the space needed for security information, and much more.

The best way to deal with these factors depends on how you want to use the information. There are no clear cut answers as to which way is best so numerous arbitrary decisions had to be made.

Regard the on disk value as only a guide. In some cases, such as with large numbers of very small files, it isn't even close. Real accuracy would only be possible if you could specify all the parameters and even experts would find that hopelessly confusing.

See this article for more information: https://blogs.msdn.microsoft.com/oldnewthing/20041228-00/?p=36863/

  • Thank you. The MFT must have a finite capacity, or at least it uses disk space all by itself and can grow, so if I put 10 billion 1 byte files on my disk, the MFT would get huge but it would be impossible to see where the space is going (without some extra tooling)? Commented Jul 25, 2017 at 14:39
  • @JoshComley there's no need for an extra tooling, Windows has built-in tools to do that. The properties on the root of the drive also shows the total free space available including hidden metadata. That's why you see some used space even on a newly formatted NTFS drive
    – phuclv
    Commented Oct 13, 2018 at 12:53

And surely folders take up some allocation space somewhere?

Yes, obviously information about every file and folder must be stored somewhere. In NTFS it's in the MFT. Those are called metadata and don't count into the file size. However in NTFS very small files can also be stored directly in the MFT entries and won't take any additional space. Those are called resident files

Your files are only 3 bytes so it's almost certainly that they all fit in the MFT, hence size on disk will be 0

Additionally, does the length of the file name matter? Shouldn't this be taken into account in an accurate calculation? Perhaps the file name length puts a 4095 byte file into two clusters on a 4096 cluster disk?

Indeed file name length can matter, along any other metadata. For example files with multiple streams, complex permissions or multiple hard links will have less space for the resident content. The size of files that can be stored in MFT varies depending on which what was stored in the entry. The more data is used for metadata in MFT, the less is left for the file.

Files smaller than approximately 900 bytes are stored within the directory entry at the MFT


The figure MFT Entry with Resident Record shows the contents of an MFT record for a small file or folder. Small files and folders (typically, 900 bytes or smaller) are entirely contained within the file’s MFT record.


However as said above, you files are so tiny that those space consumed by file names, permissions... are negligible, leaving enough space file all the files. Besides, compressed files and sparse files will also have size on disk smaller than size, since less data are actually stored on disk

Further reading

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .