"In Windows, folders are an even more extreme measure of emptiness: they take up no disk space at all. For proof, create 352,449 folders and get properties on it."
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_.
NTFS has MFT - Master File Table to store all meta-data, and it's pre-allocated to avoid fragmentation. So you won't see them taking more space until you fill the pre-allocated MFT.
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.
> It's obviously information that's stored _somewhere_.
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.
Using reserved space is still using space. Creating a folder is using up some portion of the reserved space until it will need to be expanded and take up more free space on the disk. Preemptively allocating that reserved space doesn't make the folder not take up space. If I create a file on my desktop, is it not taking up any space because I haven't yet had to expand my partition size or get another disk?
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.
> It's obviously information that's stored _somewhere_
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.
It says the folders are evaluated in alphabetical order, but actually it's evaluating them in natural sort[1][2]. This makes sense since Windows also displays folders in natural sort order.
Interesting, recently I did a test to see if the file system sorts hexadecimal numbers correctly as prefixes. It does with `less`, but looking at the definition for "natural sort order", perhaps other tools or algorithms work only with base-10.
> Natural sorting algorithms generally operate by splitting strings into "chunks" of text and numbers.
… didn’t one of the recent open api ‘escapes’ literally involve agents using path names as an ersatz message board to keep a ‘memory’ to coordinate their efforts?
Imagine being the guy trying to figure out why a Windows server is running out of space, and finding 23 million empty folders being used to define software for prod.
This is the most truly "WTF is wrong with you" esolang I've ever seen. When I got down to the syntax I imagined the amount of effort it would take to write a single statement and viscerally recoiled.
Good to see that conventional insanity is still alive and kicking, despite the meteoric rise of AI psychosis everywhere. Besides, the promise of infinite disk space does have magnetic attraction, especially on classic hard disks.
I just mentioned it to Claude and it minus-one shotted (that's when you didn't even want to make anything, just talk about it) a Python script it called Folderol that compiles .fol scripts into folder structures, and it absolutely works. But I can't thank it yet or take it up on the offers on how to follow this up, because that one response put it over from 0% to 90% of the 5-hour usage limit. I'm sure someone with some credits to spend could make this baby sing.
Just think of the applications! No seriously, can you please think of any applications and tell me?
What are cool things that can contain other things, other than folders? One thing I could think of is hypertext documents, the number of links in them could be the number of folders, and bam, you can now put complex program on the web that take up no space. And rogue agents also have a whole new way to fuck with us, too: while you try to make sense of these weird files they put into these weird folder structures, it's only about the folder structure. Not meaingless data, but active code. Watching. Evolving.
Another one is RAM compression, of course. You need some sort of JIT-compiler for the folder code -- which take up no space! -- but then you could make folder programs to store arbitrary data, and store the folder programs in RAM, using no RAM. And why shouldn't those strings themselves be .fol code that compiles to a zero footprint folder structure, right? and so on... yeah, I think you probably get it now.
"In Windows, folders are an even more extreme measure of emptiness: they take up no disk space at all. For proof, create 352,449 folders and get properties on it."
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_.
NTFS has MFT - Master File Table to store all meta-data, and it's pre-allocated to avoid fragmentation. So you won't see them taking more space until you fill the pre-allocated MFT.
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.
> It's obviously information that's stored _somewhere_.
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.
Using reserved space is still using space. Creating a folder is using up some portion of the reserved space until it will need to be expanded and take up more free space on the disk. Preemptively allocating that reserved space doesn't make the folder not take up space. If I create a file on my desktop, is it not taking up any space because I haven't yet had to expand my partition size or get another disk?
> Using reserved space is still using space.
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.
> I'm guessing this is a joke
How dare you accuse the creator of the Folders programming language of not being serious!
You're right, I feel silly even suggesting there might be the slightest tomfoolery here.
My deepest apologies to the author.
Now, look who folded.
> It's obviously information that's stored _somewhere_
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.
It says the folders are evaluated in alphabetical order, but actually it's evaluating them in natural sort[1][2]. This makes sense since Windows also displays folders in natural sort order.
[1] https://github.com/rottytooth/Folders/blob/015cf65c15ab681f5...
[2] https://en.wikipedia.org/wiki/Natural_sort_order
Interesting, recently I did a test to see if the file system sorts hexadecimal numbers correctly as prefixes. It does with `less`, but looking at the definition for "natural sort order", perhaps other tools or algorithms work only with base-10.
> Natural sorting algorithms generally operate by splitting strings into "chunks" of text and numbers.
This is so nuts and pointless... I love it!
The kind of thing no AI would ever come up with :)
… didn’t one of the recent open api ‘escapes’ literally involve agents using path names as an ersatz message board to keep a ‘memory’ to coordinate their efforts?
(Of course that had a ‘point’)
Using the file system structure to make a Smalltalk (Smalltix): https://programmingmadecomplicated.wordpress.com/2025/01/21/... (and the article that followed https://dl.acm.org/doi/10.1145/3759429.3762633 )
I can't decide if I'm in awe, or angry.
At least it looks more useful than the flying Tesla.
Imagine being the guy trying to figure out why a Windows server is running out of space, and finding 23 million empty folders being used to define software for prod.
This is the most truly "WTF is wrong with you" esolang I've ever seen. When I got down to the syntax I imagined the amount of effort it would take to write a single statement and viscerally recoiled.
If you enjoy that, allow me to introduce you to the displeasure of WORST and Malbolge.
https://esolangs.org/wiki/WORST https://esolangs.org/wiki/Malbolge
They’re both a truly bottomless pit of malaise.
> Warning: running this program at certain minute values will cause the interpreter to swap stdout and stderr.
>The same program translated to normalized Malbolge for *clarity*
The audacity
Yes, file system metadata takes space. This is so incredibly inefficient.
I don't even see a production-ready s3 client library, thank u next
> The names of the folders are ignored
Oh good, cuz naming things is hard!
The Turing machine is the [im-]practical complement: One flat file, one serialized data state, one file position.
If only Turing had foreseen folders!
This idea is so good, though
Oh, I remember that one from a CTF couple of years ago. Absolutely hilarious!
This is...beautiful.
Reading the title I immediately thought of rust
My first impression: beautiful and impressive.
absolutely unhinged, i love it
Good to see that conventional insanity is still alive and kicking, despite the meteoric rise of AI psychosis everywhere. Besides, the promise of infinite disk space does have magnetic attraction, especially on classic hard disks.
s/directories/folders !
I think you mean s/folders/directories
Uh yes I do! s/mypost/yourpost
noice!
[dead]
I just mentioned it to Claude and it minus-one shotted (that's when you didn't even want to make anything, just talk about it) a Python script it called Folderol that compiles .fol scripts into folder structures, and it absolutely works. But I can't thank it yet or take it up on the offers on how to follow this up, because that one response put it over from 0% to 90% of the 5-hour usage limit. I'm sure someone with some credits to spend could make this baby sing.
Just think of the applications! No seriously, can you please think of any applications and tell me?
What are cool things that can contain other things, other than folders? One thing I could think of is hypertext documents, the number of links in them could be the number of folders, and bam, you can now put complex program on the web that take up no space. And rogue agents also have a whole new way to fuck with us, too: while you try to make sense of these weird files they put into these weird folder structures, it's only about the folder structure. Not meaingless data, but active code. Watching. Evolving.
Another one is RAM compression, of course. You need some sort of JIT-compiler for the folder code -- which take up no space! -- but then you could make folder programs to store arbitrary data, and store the folder programs in RAM, using no RAM. And why shouldn't those strings themselves be .fol code that compiles to a zero footprint folder structure, right? and so on... yeah, I think you probably get it now.
Wow. This was exhausting to read.
Very easy to write though. That's the whole new paradigm! And now that you signed up, we have the last piece needed to actually make this work.