Why isn't it possible to name a folder "._." in Windows 7?
Solution 1:
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.
Solution 2:
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.
Source Naming Files, Paths, and Namespaces
Solution 3:
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.)
Solution 4:
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