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?
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
(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
Danger zone! If you direly want a folder name to end with
Such a directory can only be removed with
Windows seems to have a problem with dots at the end of a filename? Why is this?
The source link below goes into more details about the rules for naming.
It is not a bug. It is by design to prevent compatibility issues.
The FAT12 (floppy) and FAT16 filesystems (FAT16 prior to long filename support introduced in Windows 95) only had file-names stored in 11 bytes:
(In fact there are some other left-overs as well:
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