# Why isn't it possible to name a folder “._.” in Windows 7?

I just noticed that it is not possible to name a folder ._. - it gets named ._ instead. Sometimes, it disappears just after naming it but reappears after refreshing the view. Windows seems to have a problem with dots at the end of a filename - why is this?

• Worth noting is that you stumbled across the "hack" for starting a file name with a . in Windows. – jpmc26 Jan 19 '16 at 5:37
• @ThisNameBetterBeAvailable Untested, but cd -- -_- may possibly work. The -- is a common "end of options" marker. – TripeHound Jan 19 '16 at 11:18
• @ThisNameBetterBeAvailable No, -- on its own means "this is the end of the options, treat anytihing starting with - as a literal value". Just tested: mkdir -- -_- and cd -- -_- works as I expected. – TripeHound Jan 19 '16 at 11:30
• Alternatively, ./-_- should work as well. – glglgl Jan 19 '16 at 14:00
• @Alexander In linux, since that appears to be where the comments went, for cd "-_-" the shell uses the quotes for grouping but doesn't treat them as part of the argument; it errors with invalid option – Izkata Jan 19 '16 at 16:55

Windows normally requires files to have either no extension or an extension that is at least one character long; it's not cool with zero-length extensions, i.e. file names that end with .. Folders can have extensions too, therefore, Windows doesn't let their names end with a .. Source, from the article that DavidPostill linked:

Use a period to separate the base file name from the extension in the name of a directory or file.

(Emphasis mine.) If you try to end a file or directory named with a period, Windows just assumes you wanted no extension and so removes it, even if you create it with md in a command prompt.

Danger zone! If you direly want a folder name to end with ., you'll need to use the magic raw name override sequence of \\?\. In a command prompt, md \\?\C:\path\to\container\._. will indeed create a folder named ._., but lots of programs will have problems with it, even Explorer:

Such a directory can only be removed with rd followed by its \\?\ name or renamed with its short (8.3, dir /x) name.

• Thank you for your detailed answer! :) I think this would be a perfect folder to hide secret stuff like passwords inside of it, because you can only open the folder if you rename it first, and not everyone knows how to rename it. – Black Jan 19 '16 at 7:39
• @EdwardBlack it wouldn't stop anyone who could read stack exchange (and therefore wouldn;t even provide security against the hypothetical little brother). The name given by dir /x makes it quite easy, and there are other times this name is handy. – Chris H Jan 19 '16 at 8:53
• FWIW, Cygwin's command-line tools can also create (and manipulate) such directories on Windows 7, without using a magic sequence. – Steve Jessop Jan 19 '16 at 11:04
• @EdwardBlack As Chris H mentioned, it's not very secret, so you shouldn't store anything particularly important in such a folder. Moreover, digital secrecy and protection is a problem that has been solved many times over. You can use any number of encryption methods and programs to keep things safe without relying on obscure folder names. – Kris Harper Jan 19 '16 at 15:05
• Nitpick: At least in the 8.3 days (I haven't investigated what's written to disk on NTFS) the period was never written to the disk in the first place. The name was split into name & extension, they were stored separately. Upon reading it took the name and if there was an extension added the period and the extension to the name. Thus there existed no way to express ._. in the directory structure, of course you lost the trailing dot. – Loren Pechtel Jan 22 '16 at 4:10

### Windows seems to have a problem with dots at the end of a filename? Why is this?

Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not.

The source link below goes into more details about the rules for naming.

• This still sounds like bug to me. – ralu Jan 20 '16 at 13:40
• @ralu If it is a bug then MS appear to be totally uninteresting in fixing it. Those restrictions have been there since Windows XP (if not earlier). – DavidPostill Jan 20 '16 at 14:09
• Windows XP? My guess is that these restrictions have their roots in MS-DOS 0.x -- let's ask Mr. Gates to clear up the issue ... – Christian Severin Jan 21 '16 at 9:37

It is not a bug. It is by design to prevent compatibility issues.
It is a leftover from the old DOS days.

The FAT12 (floppy) and FAT16 filesystems (FAT16 prior to long filename support introduced in Windows 95) only had file-names stored in 11 bytes:
8 bytes for the name, 3 for the extension. The "period" between name and extension wasn't even stored. It was implied and automatically added for display purposes.
Directories didn't have extensions at all. Instead the 3 bytes for the extension were filled with "\$" characters (which were illegal in real names).
Because Windows is still compatible with this Explorer and many other components of Windows silently make the trailing period disappear to prevent creating compatibility issues.
As others have stated you can actually handle such folders by using the RAW semantics (\\?\ prefix before the absolute path-name).
Behind the scenes NTFS and network-filesystems have no problem with such files and folders. It is just a case of Explorer trying to prevent the user to create something that may cause problems for other software.

(In fact there are some other left-overs as well:
File-names like COM, COM1, COM2, AUX, PRN, LPT, LPT1, LPT2, LPT3, CON can cause similar issues where Explorer and many other Windows parts get all confused because these names are "reserved" names that also date back from the DOS era.)

• To any other readers who were initially incredulous in regard to the dot not being stored: that's correct for CP/M and all versions of FAT, including FAT16 and FAT32. – Ben N Jan 20 '16 at 22:50
• I remember some old DOS program (running on actual DOS, probably using INT13 functions directly) giving me real grief once by somehow managing to create a file named a:foo.bar on the c: drive... – rackandboneman Jan 21 '16 at 0:11
• @BenN: actually, on FAT32 it's a bit different; it stores both a short file name (8+3 bytes with "implicit dot" backwards compatible names), plus a long file name (oft-referred as LFN), made of up to 255 UCS-2 characters with explicit dot, and unless you are working with 16 bit applications, you always work with the LFN. – Matteo Italia Jan 21 '16 at 14:09
• @MatteoItalia It is my understanding that the long file names are kept in faux file entries; Windows installations that are in the know look for these entries and render them instead of the SFN if possible. See Raymond Chen's post on the subject, or the VFAT part of the FAT32 format spec I linked above. – Ben N Jan 21 '16 at 14:12
• -1 you're wrong about the directory extensions; maybe it was true for CP/M (my memory is crappy about that OS), but I've been using "programm.ing" directory in my tree since DOS times, and see win.tue.nl/~aeb/linux/fs/fat/fat-1.html - directory entries are handled exactly as files, they can have 8.3 name as well. Test: create a 8.3 directory (mkdir testfile.name) and display its DOS name in Windows (dir /x) - you'll get TESTFI~1.NAM, as expected. – user201265 Jan 22 '16 at 13:07

The problem here is that Windows (DOS) allowed for 8.3 file names on FAT file systems. Meaning, 8 characters, followed by a . followed by three characters. Unix and Linux allow for any character, except / and \0. \0 is the C character string terminator, and / is the directory separator. Everything else can be used.

Windows 95 got around this problem by maintaining a database of short (8.3) filenames to Long File Names (LFN) meta-data. If you wiped your Windows 95 OS files, you'd be left with oddly named files on the disk on your next Windows 95 install. For example, "My Documents" could be named MYDOCU~1 on the disk. Obviously, if you lost the meta-data, you'd not be able to easily convert these.

The shell has to cope with many historical increments that hang around since the MS-DOS days.

Hope this helps