When we look at the size of a file in any file management software such as the Windows Explorer, we see two different sizes, one that reads just Size and the other reads Size on disk.
Why are these two different?
Does the size on the disk include some overhead such as its entry in the File Allocation Table (FAT)? Could you please elaborate?
When we programmatically query the size of a file, it always returns the size independent of the disk size. Where does it get this number from? Does the OS have to read the contents of the entire file to determine this size or just look up the file allocation table?
Found this on Super User. What he says:
We know that a disk is made up of Tracks and Sectors. In Windows that means the OS allocates space for files in "clusters" or "allocation units".
The size of a cluster can vary, but typical ranges are from 512 bytes to 32K or more. For example, on my C:\ drive, the allocation unit is 4096 bytes. This means that Windows will allocate 4096 bytes for any file or portion of a file that is from 1 to 4096 bytes in length.
If I have a file that is 17KB (kilo bytes), then the Size on disk would be 20.48 KB (or 20480 bytes). The calculation would be 4096 (1 allocation unit) x 5 = 20480 bytes. It takes 5 allocation units to hold a 17KB file.
Another example would be if I have a file that is 2000 bytes in size. The file size on disk would be 4096 bytes. The reason is, because even though the entire file can fit inside one allocation unit, it still takes up 4096 of space (one allocation unit) on disk (only one file can use an allocation unit and cannot be shared with other files).
So the size on disk is the space of all those sectors in which the file is saved. That means,usually, the size on disk is always greater than the actual size.
So the actual size of a file(s) or folder(s) should always be taken from the Size value when viewing the properties window.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments