I often wonder why these special filenames aren't more widely known. I've been using Windows for 25 years now, but first learned about them a couple of years back when I committed a perfectly sensible (or so I thought) directory of auxiliary files from a Debian box and named it "aux/".
Cue arriving back at work on Monday with the rest of my team kicking back waiting for IT to "fix Subversion"...
I knew of NUL, CON, COM#, PRN and LPT# restrictions but never heard of AUX... today I learned two more!
"The following reserved device names cannot be used as the name of a file: CON, PRN, AUX, CLOCK$, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. In addition, any combinations of these with extensions are not allowed."
Restrictions on the File Mask and File Name Properties
I only learned about these when I was trying to scrape information about airports and save each in their own folder named after their IATA code. I learned about NUL, PRN and CON because of Nulato Airport, Pristina International Airport and Concord Municipal Airport.
Such a weird bug, I didn't know why I was getting a FileNotFoundError from trying to create a new file. Everything online will tell you the directory you're placing it in doesn't exist (it did of course), and no hint that you're trying to use a magic name.
They did it wrong then. IFF you have to map stuff to files they should all be located under /dev/ and not confuse the system if someone happens to use those strings for their own file names in their own places.
Agree but these came from DOS days, and were just always brought along for compatibility. I think it could be argued that there's such a thing as too much attention to compatibility...
Edit: MOST of the no-no file names come from DOS, not this $MFT one which is NTFS related so must have come later!
$MFT et al are not special file names. It belongs to a set of files (they are well-formed files) that make up the NTFS volume (they're in the volume root); I think the design is a bit poetic - the file system is made up of files contained in itself. While they are relatively regular files, the FS of course needs a way to bootstrap itself. To do that, the $MFT location is in the NTFS header. The other NTFS-internal files are found by lookups through the MFT - these files are always in the first few K of the MFT.
>To do that, the $MFT location is in the NTFS header.
Actually the "NTFS header" in itself (the first 8,192 bytes of the filesystem) is actually the $Boot file, which is indexed in the $MFT as residing on first cluster of the filesystem.
It's poetic, yes, but why? As you say, you already needs lots of special handling to be able to bootstrap. On the other hand, treating the files as actual files causes bugs like this one. So on what occasion would $MFT being a file (and not some special purpose data structure) actually be useful?
If I had to guess (And this guess may just be one of a list of reasons) it might just be to ensure the blocks that make-up the MFT are correctly marked/treated as 'used' and that the system knows which blocks the MFT is using.
I don't know tons about NTFS, but most/all file-systems have a way of marking which blocks in the system are currently in use, and which are free. This is usually some type of bitmap, and a quick google suggests that NTFS uses this approach as well. In the Ext file-systems, the bitmaps and metadata are a constant size and allocated when you create the file-system, so when you use the file-system you already know which blocks are being used by these structures, and thus utilities like a fsck can check that those blocks are correctly marked as used because it already knows which blocks should be marked.
In contrast, it doesn't appear that the MFT is a constant size, meaning that when you add files you may need to increase the size of the MFT. But obviously, since it isn't preallocated beforehand you can't guarantee there is always contiguous space to add to the MFT. This means you have to track which non-contiguous blocks are being used by the MFT - and that's what file entries do in the first place, track blocks being used by some entity. So you make a file entry representing the MFT, and then that file entry tells you which blocks make-up the MFT, ensuring that any fsck or similar utilities know which blocks are in use by the MFT. If you didn't do it this way, you'd basically just have to make a 'fake' file for the MFT in the NTFS's header/superblock and all utilities would have to parse that separately to get an accurate list of currently-in-use blocks - which would basically just be a duplication of the file-system structure already there. But of course, you would also avoid this $MFT bug, so it is what it is.
Perhaps what would have made sense was two "roots" to the file-system - the standard root, and a "NTFS hidden root". The $MFT and other various special files would be placed inside the hidden root (And some way of accessing that hidden root would be provided, in theory this shouldn't be extremely complicated and programs just reading the disk image could just parse both roots the same way, requiring basically no extra code), and the regular files go in the standard root. That likely wouldn't require much actual changing to the underlying structure (Obviously it would break stuff now, but when NTFS was created it likely wouldn't have been that big of a change) and would have (in theory) prevented these types of bugs while still retaining the advantages they got from making those things represented by files.
Yes I managed the same thing when I wrote a code generator to produce Java class files based on database contents and one of them ended up being named Con.java.
Cue arriving back at work on Monday with the rest of my team kicking back waiting for IT to "fix Subversion"...
(yes I did fess up :-) )