75

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?

Black
  • 7,349
  • 17
  • 40
  • 61
  • 21
    Worth noting is that you stumbled across [the "hack"](http://superuser.com/q/64471/156577) for starting a file name with a `.` in Windows. – jpmc26 Jan 19 '16 at 05:37
  • Related and possible duplicate of http://superuser.com/questions/997590/windows-unable-to-delete-file – HamZa Jan 19 '16 at 09:16
  • slightly related: linux can `cd` into `._.` but not into `-_-` because the `-_` is an invalid option – x13 Jan 19 '16 at 10:24
  • 8
    @ThisNameBetterBeAvailable Untested, but `cd -- -_-` may possibly work. The `--` is a common "end of options" marker. – TripeHound Jan 19 '16 at 11:18
  • 14
    @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
  • 3
    Alternatively, `./-_-` should work as well. – glglgl Jan 19 '16 at 14:00
  • 1
    Actually you can name a folder ._. on Windows-7 by using cygwin. – Robino Jan 19 '16 at 14:26
  • Maybe 7-Zip can help. – Ivan Chau Jan 19 '16 at 16:26
  • 5
    @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
  • 2
    Use Linux to create a file with a dot at the end, then boot into Windows and try to delete it :) – Mark K Cowan Jan 21 '16 at 22:50
  • Windows is way too liberal on naming the files, and should really be more strict - also users could demand less. Having all kinds of characters for a filename is just vanity. They are just files. I'd rather have file CONTENTS using UTF-8 and away with the encoding problems. – diynevala Jan 22 '16 at 15:09
  • 1
    @diynevala was that irony? Are you saying Windows should be even more strict? – Léo Lam Jan 25 '16 at 19:59
  • 1
    Does this answer your question? [Why does NTFS disallow the use of trailing periods in directory names?](https://superuser.com/questions/585097/why-does-ntfs-disallow-the-use-of-trailing-periods-in-directory-names) – warren Oct 07 '21 at 12:51

4 Answers4

125

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:

._. problems

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

Ben N
  • 40,045
  • 17
  • 140
  • 181
  • 1
    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 07: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 /x` makes it quite easy, and there are other times this name is handy. – Chris H Jan 19 '16 at 08:53
  • 11
    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
  • 1
    BTW, file managers like Far (http://www.farmanager.com/index.php?l=en) also operate with such directory names without that magic sequence. – Victor Jan 19 '16 at 12:14
  • 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. – Kris Harper Jan 19 '16 at 15:05
  • I know but i thought it would be maybe one more security layer – Black Jan 20 '16 at 08:31
  • @Victor: That's because Far does that for you behind the scenes. – Joey Jan 20 '16 at 20:14
  • 4
    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 04:10
  • From the linked article, it sounds like rejecting trailing dots is only done by the programs that make system calls (like Explorer, or `md` / `rd`). The actual system calls that create / use paths don't need these workaround, right? So if you're writing your own programs, and don't write code to reject such paths, your program will have no problem with them? Unless the rejection happens in some standard library wrapper that normally gets used? – Peter Cordes Jan 22 '16 at 05:27
  • 1
    @PeterCordes The normal Windows APIs that most programs use are responsible for the failure. Even `md` and `rd` can't deal with `._.` (they assume you meant `._`) unless you use the `\\?\` name. – Ben N Jan 22 '16 at 16:37
22

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

DavidPostill
  • 153,128
  • 77
  • 353
  • 394
20

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.)

Tonny
  • 29,601
  • 7
  • 52
  • 84
  • 3
    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](http://www.maverick-os.dk/FileSystemFormats/FAT16_FileSystem.html#DirectoryEntry) and [FAT32](https://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html#ss1.4). – Ben N Jan 20 '16 at 22:50
  • 1
    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 00: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. – Matteo Italia Jan 21 '16 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](http://i1.blogs.msdn.com/b/oldnewthing/archive/2011/08/26/10200583.aspx), or the VFAT part of the FAT32 format spec I linked above. – Ben N Jan 21 '16 at 14:12
  • @BenN: of course, my point is just that such "faux file entries" are actually the "real file names" that are used; the 8.3 stuff is just for backwards compatibility, you are never really working with it (unless you use 16 bit applications). – Matteo Italia Jan 21 '16 at 14:18
  • @rackandboneman Oh the joys of INT13 :) I remember the days when INT13 plus INT10 were enough to get a simple program. For something more advanced, INT21 was needed. – Aleks G Jan 21 '16 at 23:05
  • 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 https://www.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. –  Jan 22 '16 at 13:07
3

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

Ed Neville
  • 236
  • 2
  • 5
  • 2
    There 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](http://i1.blogs.msdn.com/b/oldnewthing/archive/2011/08/26/10200583.aspx). – Ben N Jan 20 '16 at 22:44