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?
4 Answers
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.
-
1Thank 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.– BlackJan 19, 2016 at 7:39
-
19@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 /xmakes it quite easy, and there are other times this name is handy.– Chris HJan 19, 2016 at 8:53 -
11FWIW, Cygwin's command-line tools can also create (and manipulate) such directories on Windows 7, without using a magic sequence. Jan 19, 2016 at 11:04
-
4@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. Jan 19, 2016 at 15:05
-
4Nitpick: 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. Jan 22, 2016 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.
answered Jan 18, 2016 at 21:04
-
5
-
@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, 2016 at 14:09
-
2Windows 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 ... Jan 21, 2016 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.)
-
3
-
1I 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... Jan 21, 2016 at 0:11
-
2@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. Jan 21, 2016 at 14:09
-
1@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 NJan 21, 2016 at 14:12
-
2-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 getTESTFI~1.NAM, as expected.– user201265Jan 22, 2016 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
-
2There wasn't really a database per se; Windows just jammed the parts of the long filename onto the disk as faux-files. See Raymond Chen's post on the subject.– Ben NJan 20, 2016 at 22:44
.in Windows.cd -- -_-may possibly work. The--is a common "end of options" marker.--on its own means "this is the end of the options, treat anytihing starting with-as a literal value". Just tested:mkdir -- -_-andcd -- -_-works as I expected../-_-should work as well.cd "-_-"the shell uses the quotes for grouping but doesn't treat them as part of the argument; it errors withinvalid option