75
16
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
Posted 2016-01-18T20:57:57.123
Reputation: 3 900
124
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.
Ben N
Posted 2016-01-18T20:57:57.123
Reputation: 32 973
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. – Black – 2016-01-19T07:39:16.617
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 – 2016-01-19T08:53:49.503
11FWIW, Cygwin's command-line tools can also create (and manipulate) such directories on Windows 7, without using a magic sequence. – Steve Jessop – 2016-01-19T11:04:53.853
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 – 2016-01-19T12:14:41.4134@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 – 2016-01-19T15:05:36.697
I know but i thought it would be maybe one more security layer – Black – 2016-01-20T08:31:57.807
@Victor: That's because Far does that for you behind the scenes. – Joey – 2016-01-20T20:14:49.037
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. – Loren Pechtel – 2016-01-22T04:10:08.520
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 – 2016-01-22T05:27:09.897
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 – 2016-01-22T16:37:58.560
22
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.
DavidPostill
Posted 2016-01-18T20:57:57.123
Reputation: 118 938
5This still sounds like bug to me. – ralu – 2016-01-20T13:40:09.287
@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 – 2016-01-20T14:09:37.290
1Windows 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 – 2016-01-21T09:37:37.867
19
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
Posted 2016-01-18T20:57:57.123
Reputation: 19 919
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 and FAT32.
– Ben N – 2016-01-20T22:50:55.4671I 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 – 2016-01-21T00:11:11.043
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 – 2016-01-21T14:09:28.257
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 N – 2016-01-21T14:12:14.420@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 – 2016-01-21T14:18:56.630
@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 – 2016-01-21T23:05:13.893
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.
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
Posted 2016-01-18T20:57:57.123
Reputation: 236
1
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.
– Ben N – 2016-01-20T22:44:00.230
21
Worth noting is that you stumbled across the "hack" for starting a file name with a
– jpmc26 – 2016-01-19T05:37:41.720.in Windows.Related and possible duplicate of http://superuser.com/questions/997590/windows-unable-to-delete-file
– HamZa – 2016-01-19T09:16:03.390slightly related: linux can
cdinto._.but not into-_-because the-_is an invalid option – x13 – 2016-01-19T10:24:24.4808@ThisNameBetterBeAvailable Untested, but
cd -- -_-may possibly work. The--is a common "end of options" marker. – TripeHound – 2016-01-19T11:18:50.07014@ThisNameBetterBeAvailable No,
--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. – TripeHound – 2016-01-19T11:30:08.4173Alternatively,
./-_-should work as well. – glglgl – 2016-01-19T14:00:58.5801Actually you can name a folder ._. on Windows-7 by using cygwin. – Robino – 2016-01-19T14:26:42.227
Maybe 7-Zip can help. – Ivan Chau – 2016-01-19T16:26:39.260
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 withinvalid option– Izkata – 2016-01-19T16:55:57.5632Use Linux to create a file with a dot at the end, then boot into Windows and try to delete it :) – Mark K Cowan – 2016-01-21T22:50:33.187
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 – 2016-01-22T15:09:25.493
1@diynevala was that irony? Are you saying Windows should be even more strict? – Léo Lam – 2016-01-25T19:59:06.497