There is a secret list of filnames that Microsoft
does NOT want you to use. So much so that in Windows, you literally
cannot make any files using these names. In reality things aren't as sinister as I
made it sound, but it is true, and actually interesting for why. And even if you've heard of these forbidden
filenames, stick around because I'm going to go over a lot more about similar stuff
you probably don't know. Now you may have actually seen these forbidden
filenames mentioned before, they are: AUX, CON, PRN, NUL, and LPT0 through 9, and COM0
through 9. For the last ones you can do just COM or LPT,
or even COM10 or COM[some letter], it just can't be a single digit after. And these are forbidden no matter what file
extension you add, or no file extension. Of course I'll get into what these all are
for later and why they're forbidden. But actually, here's one thing I bet you didn't
know about these even if you've heard of them. Because LPT and COM don't just forbid number
digits after them, but also certain unicode number digits as well, for example, superscript
1, 2 and 3, after these also won't let you make the file. And instead of the previous error, it says
"could not find this item", I suspect because Windows still doesn't allow the file to be
made, but they forgot to include these when coding for the special error message. I couldn't actually find any more special
characters that were forbidden besides these three superscripts, and even all the subscript
numbers, and superscripts from 4 to 9 are allowed. It may be because the superscript numbers
1 to 3 are grouped with other latin digits in the Unicode standard, having a code starting
with 00, while the rest are categorized as 'superscript' and start with 20. Any my point here is I'm not sure if there
are any more digits that cause the forbidden filename, but those are the only three I could
find. Now all those filenames I mentioned before
are actually forbidden at the Windows level, not the filesystem level, so you can technically
create these files if you know how. Before we get to that though, there ARE actually
some so-called 'Reserved' filenames in the NTFS filesystem, which is what Windows uses. Which means you cannot create these filenames
no matter what, though these only apply in the top, root directory of a drive. These reserved file names are the following,
and they all start with a dollar sign but I won't read that. They're: $Mft, $MftMirr, $LogFile, $Volume,
$AttrDef, $Bitmap, $Boot, $BadClus, and then you can just read off the rest. All of these reserved names are for what are
called NTFS metadata files or metafiles, and there is one that's a folder actually. But basically you can't see these files anywhere
in Windows at all, even if you enable viewing hidden system files, they're completely invisible. They store really important info about the
NTFS filesystem itself, such as including the Master File Table, which is a file that
stores info about all files and folders on your whole disk. So if you've ever wondered why an empty file
is shown as being zero bytes, even though it has a name and stuff, you'd think that
must take up data, it does but that data is put in the MFT. If you want you can look up what the different
NTFS metadata files actually do, but I'm not gonna get into it. Now to be able to see these files at all,
like I said you can't use Windows explorer or anything like that, you have to use special
software, for example one I found is called OSForensics, it's actually pretty cool. You can see that these are all pretty much
files, with the exception of $Extended which is actually a folder. So now it should become obvious why you can't
create files or folders with these names, it's because they already exist. Also when I was looking through this list
at first I couldn't find a couple of them like $ObjID and $Quota and $Reparse, but then
I actually found them inside the $Extended folder, so some of these are in there. You can try making a couple of these, but
you won't be able to. It will either say, already exists, or access
denied. And it might confuse you if you can't see
it in there at all, but yes it does exist. You might be wondering, why can't you create
even folders with these names if they're just meant for and used by files. Well here's a fun fact, in all filesystems
I believe including NTFS, two files and/or folders within the same directory cannot have
the same exact name. Go ahead, try making a folder called "test.txt"
and then in the same place, try to make a file with the same name, it won't let you. Again, the file extensions have to also match
to be a problem, but this includes folders and files with no file extension. So that's why in the top level directory,
you can't even make folders with those names, because it still conflicts with the file names. Alright so that all makes sense for the filesystem
reserved names, but why is that other group of filenames forbidden, and what do those
names even mean? Well notice when you try to create one, the
error message says something strange: "The specified DEVICE name is invalid." It doesn't say file name, it says device name,
but you tried to make a file or folder, what's going on? Well that error message is actually a hint
to the answer, which I'll explain now. You see in the world of operating systems,
there can be what are called "Device Files". They are basically special files that aren't
really files in the normal sense, but rather act as a connection between an actual device
and any app that wants to use it. So for a super simplified example, say you're
using old MS-DOS and want to print a text file called 'whatever.txt'. You'd start with a command something like:
"TYPE whatever.txt", where the TYPE command displays the contents of the file to the screen. But if you want to print it, you could instead
do "TYPE whatever.txt > PRN", where PRN is the name of the device file for a printer. This command then directs the results not
to the screen, but rather into PRN, which actually ends up at the parallel port that
goes to the printer. Though there is a device driver that takes
in whatever is put into the device file, then does some work to prepare the data it before
actually sends it out the port. This is way of doing things is nice because
it's sort of modular. The program doesn't have to know anything
about how the device works, it just puts the data into the device file, and for all the
program knows, it is just writing to a regular file. Then each devices driver will take it from
there. So now that you know what device files are,
you might like to know that all the fordbidden filenames mentioned all at the beginning,
are indeed device file names that date back to MS-DOS, and yes I will quickly go over
each one and then why they're still reserved. And later I'll also go over even more related
restrictions on filenames and stuff, because yes, there are more. First up is the CON device file. It's short for 'Console Input and Output',
and was used for text input or text output to the console, and usually this just meant
a keyboard. So yes, actually, device files could be used
for taking data in from devices, not just sending it out. Next is AUX, short for 'Auxiliary input and
output', and apparently was the same idea as CON, but was instead for 'something else'
besides a keyboard, like maybe a remote terminal or something. NUL is an interesting one. It's a so-called 'Null Device', aka a black
hole, and it just discards whatever data is written to it. Typically something like this is used for
disposing unwanted data streams or outputs. For example, maybe you make a program that
uses some command that normally outputs a bunch of unnecessary text to the display,
but you could instead easily redirect it to the Null Device to hide it, so users don't
have to deal with it cluttering up on the screen. Up next are the LPT# devices. LPT is apparently short for several names
people used but all referred to the same thing, specifically: "Line Print Terminal", "Local
Print Terminal", and "Line Printer". The numbers on the end were just to handle
multiple of these types of devices, and all of these were used for parallel ports, and
usually for printers specifically, but could have been other peripherals too. And a parallel port is just a kind of port
that sends multiple bits of data at once, but the data all has to be recombined and
synced at the end. Now I already mentioned the PRN device file
before, and actually PRN was usually just an alias for LPT1, it did the exact same thing,
because LPT1 was commonly used for the first printer port. So PRN was basically just a more memorable
and friendly name than LPT1, but you could have just used either, it would have done
the same thing. Alright then we have the COM# names, which
are short for 'Serial Communications' ports, which like the name suggests, were serial
ports, as opposed to parallel ports. These were also used for miscellaneous peripherals
or really anything, and serial data just means the data is sent or received one bit at a
time, sequentially and back to back. As a quick side note, you might be thinking,
"haha serial ports, that's so old and slow". But actually, serial communication is still
used all around us, maybe even for most things. Not this old slow port anymore obviously,
but using improved protocols and hardware. Serial is more reliable and not as complicated
as parallel transmission because it doesn't rely on different streams arriving out of
sync for example. Serial is by stuff you use all the time, such
as Ethernet, Sata (Serial ATA), and yes even USB - Universal Serial Bus. Anyway I'm getting off topic, but if you want
to know why parallel is not more common, I'll link to this article on HowToGeek which explains
it well. So now we have to ask, if these device file
names were used back in MS-DOS, why are they still forbidden or reserved? And the answer is backwards compatibility,
and a bit of computer Windows history. You see back in the earliest versions of MS-DOS,
there was only one directory, so if you wanted to use a device file, you didn't have to specify
where it was because it's always right there, you just put the device name. So the names basically worked like commands
for a while, and a ton of programs were written that way. But later on directories were added, and device
files could be hidden away in their own directory such as /dev/whateverdevice, so programs also
had to start specifying the whole location. Though the new versions of DOS still needed
to support existing programs in order to get people to upgrade. But the problem here was that now, these programs
could be run from any directory, and weren't updated to use the new file location, and
they always just assumed the device file was always in the same directory. Therefore, to prevent old programs from from
breaking, you couldn't allow any file anywhere to have those certain names, because if a
program happened to try to use a device file while in a directory that had such a real
file, it would conflict with the virtual device file. Anyway, it made sense for Microsoft to support
these old programs in versions of DOS and Windows released soon after that one. And in every single version since though,
they've continued to support these programs that must be ancient by now. But I guess they figure, for the price of
just a few filenames almost no one will even notice, it's worth it in case someone, somewhere
needs to use one of these ancient programs for something important. That being said, not all operating systems
feel this way. And like I mentioned before, these device
name files are reserved only by Windows at the operating system level, but they technically
are valid NTFS names. In fact, you can actually create these files
not just using another operating system like Linux, but also within Windows itself using
what's called UNC, or "Universal Naming Convention", which is supported by Windows in some places. A naming convention just means a way a computer
path is written. UNC is the same naming convention you might
see when accessing a network device for example, and it's written like \\servername\folder\whatever. So because network devices may be using operating
systems other than windows, which don't respect these reserved names, Windows will bypass
the reserved name checks whenever you are using this naming convention, or at least
in programs that support UNC, such as powershell. Now I'm going to show you how you can make
a 'forbidden file', but I recommend you do NOT, and I'll explain why right after, so
don't just go and do this. In powershell I could do the command: "New-Item
-Path" then for the path, in UNC for a local device, not a network device, you use either
\\?\ or \\.\ - (and I mean backslashes, but it's easier to say slash) - then you put the
drive letter, in this case a thumb drive M:\, then I'll put it in a folder called 'Broken\',
then the file name itself, COM1.txt for example, and then the parameter -ItemType File. (as
opposed to folder). Now again I would NOT suggest doing this,
and you're about to see why, and also why I chose to put this on a USB drive. Because the file does now exist, however you'll
notice it cannot be copied, moved, or even deleted by Windows explorer! And even if it's in a folder, you can't delete
the folder it's in! Theoretically I should also be able to use
powershell to delete the file too. But for me, for some reason, I couldn't get
regular powershell to do it. I had to use Powershell Core 7, which is a
newer separate version of Powershell, but is also a separate download, it's not included
with Windows. I don't know if I just was using the wrong
syntax or whatever, but just save yourself the headache and don't create a forbidden
file unless you know what you're doing. But wait, no, we're not quite done yet, because
there are some more related restrictions in Windows we can mention. For example, you probably know that there
are several forbidden characters that can't be used in any Windows filename. It's these characters here, and they'll pop
up any time you try and use them, including quotes, question mark, colon, and a few others
it tells you. But there are lots more, specifically if you
look at the ASCII character table, all characters of identifying integer value 0 through 31
cannot be used in file or folder names. Though most of these are invisible characters,
for example the first one with index 0 is the 'Null Character', which has no symbol
so it's invisible, and basically means nothing. These days Null character is usually use to
signify the end of a string for example. But again, almost all of these restrictions
only apply in Windows. In Linux for example, you can use any character
except for the null character, and the forward slash, that's the only restriction, because
that's used for separating folders in paths. And I believe the null character is used to
signify the end of a filename, so the operating system really needs to use those. But anything else is fair game. But in this case I would also again not recommend
using linux to add files with these characters onto a drive used by Windows, because Windows
will start to misbehave with these just like the other example I showed. Alright, now the final restrction we'll talk
about is path length limits. You might not know that Windows typically
restricts the maximum path length of any file or folder to 255 characters. And I don't mean the filename length, I mean
the whole path. So something like C:\Users\Joe\Desktop\whatever.txt,
all the characters in that path count towards the limit. This is good to know because if you have super
deep levels of folders in some place on your drive, you could run into problems. One example might be if you're moving one
folder that has lots of subfolders, into another folder that's already at a pretty deep directory
level. Windows might move a bunch of the files, but
then stop and throw an error once it gets to any that are too long. And then that could mess up your whole process
of thinking, because some files have copied, some haven't, you have to rename the things
to make sure the directories aren't too long before copying it again, it would be a mess. That being said, recent versions of Windows
10 do actually allow you to change this in the registry, and effectively remove the path
length limit, but really it sets it to like 62,000 characters. Though I would actually suggest you don't
do this, for the sake of compatibility. Because it's not default, and almost all Windows
computers still have this limit. So say you do a backup of your hard drive
and it happens to have a ton of deep folders beyond the normal limit. If you want to access or copy that drive back
using another computer, you won't be able to access any folders that are in those deeper
levels until you re-enable it on the other computer, you can't even look into them. You might think, well then I'd just re-enable
it! But what if it's not your computer, and say
you've been storing files on your thumb drive and exceed the limit without knowing, then
take the files to work, or school, or somewhere else they don't exactly want you messing with
the registry, well then you can't get to some of those files. So it's good to at least know that you can
remove the limit, like if you do come across that situation from a drive someone else gave
to you. So yea pretty much everything I talked about
in this video was all extreme edge cases, but if you've watched this long hopefully
you found it interesting. If you did, consider subscribing for new videos
every week and also like the video because not everyone does. If you want to keep watching, the next video
I'd recommend is where I talk about the different AppData folders in Windows and what they're
fore, you should like that too. So thanks for watching, and I'll see you in
the next one.
