I'm guessing this is a joke and I'm just taking it too seriously, but the only thing that "proves" is that Windows lies to you lol. It's obviously information that's stored _somewhere_.
I'm guessing this is a joke and I'm just taking it too seriously, but the only thing that "proves" is that Windows lies to you lol. It's obviously information that's stored _somewhere_.
There are other file-systems which do that kind of a thing. But NTFS has fairly large records - 1024 bytes, so it can fit even small files inside MFT.
Yes, but it is a pre-allocated somewhere (part of the MFT) so no extra space is taken until a directory grows really huge or there is enough stuff using the MFT that it needs to be expanded. IIRC each directory will be taking a 1Kbyte block in the MFT in an experiment like this, plus a bit for the directory they are in needing to consume more blocks to describe them.
Similar to creating lots of very short files might not initially take any space on common Linux filesystems, as they use nothing more than the pre-allocated inodes.
Yes. But not using space from the pot that people are usually meaning when they talk about available space, the amount listed in the `avail` column in the output from `du`, or the space free number displayed by Windows Explorer and other GUI file managers.
Not that it usually makes much difference in the grand scheme of things, outside of made up examples like those mentioned above, or specific cases like file-per-message mail/usenet stores where you could easily run it of inodes before running out of main storage space on a filesystem and small files not taking more than the one inode (no extra storage block) could save a significant amount of main space in total.
How dare you accuse the creator of the Folders programming language of not being serious!
My deepest apologies to the author.
It's likely stored in the disk blocks reserved for the filesystem metadata. The disk may always appear empty, but available space will get lower and lower eventually.