128

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

Improve this question
3
  • 5
    Short answer: If no additional space on disk is needed to store its contents.
    – David Schwartz
    Commented Jan 25, 2016 at 1:52
  • 11
    @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
    Commented Jan 25, 2016 at 16:41
  • 3
    Related: How can an large file have a zero “Size on disk” value?
    – BlueRaja - Danny Pflughoeft
    Commented Jan 26, 2016 at 0:36

1 Answer 1

Reset to default
185

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'?

Improve this answer
10
  • 2
    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
    Commented Jan 24, 2016 at 23:24
  • 9
    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
    Commented Jan 24, 2016 at 23:29
  • 9
    @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
    Commented Jan 25, 2016 at 0:33
  • 7
    @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
    Commented Jan 25, 2016 at 12:25
  • 4
    @Philipp: Anyway, including the bookkeeping in the file-size gets hairy fast: How would you describe a 1-cluster file with 3 names?
    – Deduplicator
    Commented Jan 25, 2016 at 13:29

You must log in to answer this question.

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