ItsGeekToMe.co

Q: I was recently doing some routine file work on a Windows 10 system. I noticed that for one particular file, the directory listing showed that it had over 400 bytes of data in it, but when I looked at the file’s Properties window, it showed the “Size on Disk” as zero bytes. How can that be?

– Chris B.
Navarre, Florida

A: For as long as Windows has been around as an operating system, some mighty odd quirks have persisted within its core file-handling abilities. For example, dating all the way back to the original version of MS-DOS released in 1981, if you copy a single file from a command prompt, Windows replies “1 file(s) copied.” Now, speaking as a software engineer, I can tell you with confidence that it is a trivial matter to write an algorithm that examines the number of files in a copy operation, and if it was one, outputs the word “file” and if was more than one, outputs “files”. That cheesy parenthetical s is just lazy programming (thanks, Bill!).

But, I digress. Your issue doesn’t go back as far as 1981, but it does exist, and it can be quite confusing until you know what’s going on. Fully understanding this is going to require a little explanation. Caution, geekiness lies ahead!

Prior to Windows NT 3.1 (circa July 1993) Windows used a system called File Allocation Table, or FAT to manage file storage on various storage media. FAT provides necessary functions such as the ability to assign file names, allocate physical space to store the file in units called clusters, and facilitate the quick seeking of a hard drive’s read/write head to minimize wear and tear on the hardware. FAT had some limitations, however. It could not handle what at the time were considered very large files, or even disk drives over about 4 GB. So in 1993 a new system was introduced, named the New Technology File System, or NTFS. For a brief time, Microsoft fielded versions of Windows that used FAT, marketed to home users, and NTFS, marketed to businesses. The release of Windows XP in 2003 marked the end of versions of Window’s use of FAT, and NTFS became its the exclusive file system.

So, what does all that have to do with the problem? I’m getting there. When NTFS creates a file, it first creates a file record in NTFS’s Master File Table (MFT). This record contains all of the information that the operating system needs to know about the file. When it creates new records, it allocates a certain amount of space to hold the file’s attributes, security settings, and so forth. There can be anywhere from 512 to 1024 bytes of leftover space in the file record when this process is complete.

The “gotcha” part of your question is that part about “Size on Disk”. When NTFS allocates actual disk space to store a file, the smallest amount of space it can request is one cluster. Now, a drive’s cluster size is set when it’s first formatted. Generally, for efficiency, the larger the hard drive, the larger the cluster size, which can be several hundred thousand bytes. That would mean the smallest possible “Size on Disk” would be several hundred thousand bytes, even though a file might only actually contain 400 bytes of actual data. The rest is wasted, empty storage. However, NTFS has a little trick up its sleeve. For small files, it stores their data right in that leftover space in the file record. Since it never allocates any clusters, and since the file record belongs to NTFS and not the file, the data wind up taking up zero space on the disk, and you get that confusing message “Size on disk: 0 bytes”. What it really means is, “This file’s data is stored within the NTFS file record. Therefore, the size of clusters allocated to store the file data is 0 bytes” I hope it’s not so confusing anymore!