Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a file in Windows 10 with 362 bytes of data, but the "size on disk" is just 0 bytes. It's a simple "Hello world" program written in assembly, and saved in Notepad++.

How is it possible that the size on disk is zero when the size of the file is 362 bytes?

I have an SSD, not a normal hard disk.

Screenshot of the Properties dialog:

Screenshot of the Properties dialog

share|improve this question
3  
Short answer: If no additional space on disk is needed to store its contents. – David Schwartz Jan 25 at 1:52
9  
@Thomas Not a duplicate. The name sounds similar, but that question is asking why Windows declares a zero-byte file to be zero-size despite requiring registration somewhere. This question asks why the size on disk can be zero even if there is data in the file. – Ben N Jan 25 at 16:41
2  
    
@BenN Is flagging it inappropriate because you are right it is certainly not a duplicate. – William Jan 29 at 6:44
    
Hi Coder88, I believe the person who flagged your post as a duplicate was mistaken - the other question was asking something different; you really did ask a good question. If you meant to indicate that your question is solved, you can click the check mark next to an answer here. – Ben N Jan 29 at 19:31
up vote 134 down vote accepted

This happens if the file is so small that its contents and the filesystem bookkeeping fit in 1KB. To save disk space, NTFS keeps small files "resident", storing their contents right in the file record, so no cluster has to be allocated for it. Therefore, the size on disk is zero because there's nothing beyond the file record. Once the file gets sufficiently large, NTFS makes it "nonresident", allocates one or more clusters for it (creating a nonzero "size on disk"), and creates a "mapping pair" in the file record in the place of the data to point to the cluster.

SSD hard drives or Windows 10 don't affect this; it's simply an NTFS feature. Further reading: The Four Stages of NTFS File Growth.

Note that the "size on disk" metric isn't exactly right. For instance, it never includes the constant 1KB that the NTFS file record takes up. The metric was introduced in Windows 95, which didn't use NTFS and therefore couldn't have accounted for this phenomenon; it just showed the file size rounded up to the next multiple of the cluster size. That estimation algorithm was carried through to Windows 7, even though many Windows versions between them used NTFS and resident storage. It was finally updated in Windows 8 to count files with only resident data as zero-size on disk. Further reading: Just What Is 'Size on Disk'?

share|improve this answer
1  
For a moment I thought we were looking at the effects of Data Deduplication (blog.fosketts.net/2012/01/03/…) but I believe that feature works at a level transparent to something like the "size on disk" metric. – misha256 Jan 24 at 23:24
7  
But wait... I am unable to replicate the OPs behavior on my NTFS volume (Windows 7). Regardless of how I create tiny files (some just one-byte long), they each occupy 4KB "disk space" according to the File Properties dialog. Hmm... – misha256 Jan 24 at 23:29
7  
@misha256 Huh, I can reproduce it with a file under ~700 bytes on Windows 8.1. My guess is that the algorithm became smarter somewhere between Windows 7 and 8.1, since originally, it didn't know about any fancy NTFS stuff (source). Note that once a file goes over into the second stage, it never shrinks back down. – Ben N Jan 25 at 0:33
1  
Isn't that still a misrepresentation of storage use? Shouldn't the "size on disk" in the file property dialog also count the size of the NTFS file record entry for every file? – Philipp Jan 25 at 10:15
5  
@Philipp I guess one could argue either way. Traditionally, the "file on disk" was "the size of allocated clusters" (so, for instance, you could see the effects of choosing too large a cluster size). It has never, to my knowledge, included the "catalogue" space needed by the file system (e.g. the size of the "directory entry" or "the length of the chain of FAT entries"). – TripeHound Jan 25 at 12:25

protected by Raystafarian Feb 22 at 17:51

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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