Size on Disk: strange results.

[NotNull]

Small files (<800 bytes) will typically end up in $MFT, instead of on disk. Everything thinks otherwise
(4096 is the clustersize of the volume)

2023-04-24 17_43_03-c__test__testdata_empty1 - Everything (1.5a) 1.5.0.1343a (x64).png (84.82 KiB) Viewed 7132 times

[ChrisGreaves]

Small files (<800 bytes) will typically end up in $MFT, instead of on disk. Everything thinks otherwise

Hi NotNull.

To the best of my limited knowledge, a "folder" is represented by a file. That file belongs to Windows and is initialized as what we used to call a Directory.
Such a file - to us a directory but to Windows a file of data that describes files - ought to occupy a cluster-size amount of disk space.

I find it easiest to think of metal filing cabinets. On the front of each drawer in a four-drawer filing cabinet is an A4-size sheet of paper that lists the projects (or accounts) in that drawer. The number of projects on each label may vary, but the label is always an A4-size sheet of paper.
That A4-size sheet of paper is a cluster, and since we don't clip edges off the paper (so we can pencil in new projects as we start them), so the A4-size sheet of paper corresponds to the cluster size set aside for the directory.

And yes, the last entry in a directory waits to hold the pointer to the next cluster (A4 sheet of paper) that carries the overflow of names.

If I have understood your screen snapshot, Everything is reporting 4,096 bytes (=== one cluster) which is what I expect the size of an A4 sheet of paper to be before we apply ink!

I think that that makes sense to me, and I hope that it makes sense to you.
Cheers, Chris

[NotNull]

It does make sense. That is how it always used to be. But NTFS filesystems have a trick up their sleeve ...

The Master File Table (MFT, the internal "address book" of all files and folders) reserves 1kB for each record. Some of the fields in this record are fixed width (date/time), some have a variable width (filename).
In daily use, the 1kB is not fully written -- not every filename consist of 255 characters -- so there might be some space left. 400-800 bytes is quite common. Especially since security settings (who has access to this file/folder?) are stored separately these days.


It is a bit of a waste to dedicate an entire drawer for just one single little piece of paper. So NTFS tries to reside the content of the file *inside* the MFT to save this space. Like a post-in in the address book, if you will.
If there is not enough space, it will be stored in one or more drawers, like usual.
And if the post-it data grows in the future, it will also be put in drawers (and to answer your next question: no, the data in the MFT will not be cleaned)


And that is why Windows reports that the size on disk is zero bytes.

[NotNull]

Hmm .. should have done a forum search first ...

Technical update: In Everything, Size on Disk is the Allocation Size rounded up to the nearest cluster size.

Allocation Size is a multiple of the volume cluster size.
Except, when the file is small and fits directly in the MFT, then the Allocation Size is the size in the MFT.
(doesn't have to be a multiple of the volume cluster size)

[therube]

OK, but smallfile.txt is 6 bytes (abcdef), but Size on Disk is 8 bytes, so what there is 2 bytes overhead there?

[NotNull]

the size in the MFT

I assume this is including end of field marker

[ChrisGreaves]

It does make sense....

Thanks NotNull, and Fair enough.

For anyone else reading this, my "file cabinet drawers" are large, heavy, on rollers, and contain many hanging folders, each of which can contain none, one or more manila folders each of which .. none, one or more stapled documents ... each of which ... sheets of paper. There is a hierarchy of data implicit in all of this.

My idea of the A4-sheet labels is usually a card about two inches by three inches that drops into a slotted holder on the face of the filinmg cabinet drawer.

I am Real Old World you see

Cheers, Chris

[void]

Everything will show the "allocation size" for size on disk.

Files stored in the MFT will still take up some room on disk.

Allocation size will typically be a multiple of the cluster size.
An allocation size less than the cluster size means the file is stored in the MFT.

To find files stored in the MFT, include the following in your search:
sizeondisk:<4096
where 4096 is the cluster size.



Everything is currently incorrectly rounding up the allocation size to the nearest cluster size for total size on disk.
I'll have this fixed in the next alpha update.

[froggie]

Files stored in the MFT will still take up some room on disk.

I'm confused. If the file is stored in the MFT, which is a fixed 1K record, what other room will the file take up on disk?

[void]

The MFT record will use disk space.
Typically 1k.
The allocation size is within this 1k MFT record.

There's no extra disk space used.
It's how much size is allocated from the MFT record, which would otherwise be unused space.

I'll make Everything show the same as Windows Explorer to help avoid confusion.

[NotNull]

OK, but smallfile.txt is 6 bytes (abcdef), but Size on Disk is 8 bytes, so what there is 2 bytes overhead there?

This question kept nagging my brain ...
It turns out that filedata that is stored in the MFT uses chunks of 8 bytes:

2023-04-25 11_09_34-t__folder - Everything (1.5a) 1.5.0.1343a (x64).png (48.53 KiB) Viewed 7049 times

Makes sense (in hindsight ...)

FWIW: In this case, a file of 736 bytes was the largest that still fitted in the MFT

[...]I'm confused. If the file is stored in the MFT, which is a fixed 1K record, [...]

To add to your confusion :
Each record in the MFT is exactly 1kB. A file/folder might need more than 1 kB to store all information. Depending on what type of information, an extra 1kB record will be used (for resident datathat *has to* be in the MFT, according to specifications) or that information will be stored in a cluster on disk (for non-resident data)

[froggie]

I'll make Everything show the same as Windows Explorer to help avoid confusion.

Speaking of confusion -- for files stored in the MFT Win10 Explorer-Properties reports Size on Disk as 0 bytes, as it should.

Win7 reports 4096 bytes for the same file, as does Win/XP (in a VM), which is an error that has been around for a long time.

[NotNull]

Win7 reports 4096 bytes for the same file, as does Win/XP

Thanks for this, @froggie!

(if your VM is still alive: what foldersizes are reported by Windows? )

[froggie]

(if your VM is still alive: what foldersizes are reported by Windows? )

Not sure what you are asking for, but

Win7 & Win/XP show an empty folder as zero bytes on disk, a folder with a single 2 byte file as 4096 and one with two 2 byte files as 8192 - it is just adding up the incorrect file sizes.

[NotNull]

That is exactly what I was asking for. Good guess Thanks!

[void]

The next alpha update will match the OS. (tested on XP/7/8/10/11)

I'll also add an ini option to specify the size on disk type. (use system default, mft zero (>=win10), cluster size ceil (<win10), allocation size)

[void]

Everything 1.5.0.1344a will now show the same Size on Disk value as the OS.

Since this changes for each OS, I've added a setting so you can choose your preferred method.

To change the Size on Disk method:

• In Everything 1.5, from the Tools menu, click Options.
  Click the Advanced tab on the left.
  To the right of Show settings containing, search for:
  disk
  Select size_on_disk_type.
  Set the value to one of the following:
  • (Use default)
  • MFT zero - Files stored in the MFT show a size of zero. Otherwise, round up to cluster size (Windows 10+)
  • Cluster ceil - Round up the file size to volume cluster size. (Windows 8 and earlier)
  • Allocation size - Show the true allocation size on disk.
• Click OK.

size_on_disk_type