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 :-) )
"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
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.
https://blogs.msdn.microsoft.com/oldnewthing/20031022-00/?p=...
Edit: MOST of the no-no file names come from DOS, not this $MFT one which is NTFS related so must have come later!
I'm convinced that most problems people face are rooted in the conflict between short and long term goals.
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.
Ouroboros:
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.
"Peter, you know you wanted the login 'PRN'? Yes, your initials. Well, you'll never guess what ..."
Yup, had to rename the account to "PN".