On Sat, Dec 11, 2021 at 03:04:53AM +0100, Pali Rohár wrote: > I tried to find some information what is allowed and what not. > > On Monday 27 September 2021 12:19:48 Sean Young wrote: > > Windows allows files and directories called "." and ".." to be created > > using UNC paths, i.e. "\\?\D:\..". Now this is totally insane behaviour, > > but when an exfat filesytem with such a file is mounted on Linux, those > > files show up as another directory and its contents is inaccessible. > > > > I can replicate this using exfat filesystems, but not ntfs. > > Microsoft exFAT specification explicitly disallow "." and "..", see: [...] > On the other hand Microsoft FAT32 specification can be understood that > file may have long name (vfat) set to "." or ".." but not short name. [...] > OSTA UDF 2.60 specification does not disallow "." and ".." entries, but [...] > So it means that "." and ".." entries could be stored on disk as valid > file names. It doesn't matter one whit what the specification says. Anyone with a disk editor can craft a filesystem containing filenames such as "." or "..", "/" "foo/bar" or anything else we would like to ban. > > So, in Linux cannot read "." or ".." (i.e., I can't see "Hello, World!"). I > > don't know what the correct handling should be, but having two "." and two > > ".." files does not seem right at all. > > This is really a bug in Linux kernel. It should not export "." and ".." > into VFS even when filesystem disk format supports such insane file > names. This. Otherwise, every filesystem driver would need to contain redundant code for checking for such bad names. > So either Linux needs to completely hide these insane file names from > VFS or translate them to something which do not conflict with other > files in correct directory. Escaping bad names has the problem of the escaped name also possibly existing -- perhaps even recursively. Plus, the filesystem might be using hashed or tree indices which could go wrong if a name is altered. But then, I once proposed (and I'm pondering reviving) a ban for characters \x01..\x1f and possibly others, and if banned, they can still legitimately occur in old filesystems. > I guess that hiding them for exfat is valid thing as Microsoft > specification explicitly disallow them. Probably fsck.exfat can be teach > to rename these files and/or put them to lost+found directory. fsck fixing those is a good thing but we still need to handle them at runtime. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- <willmore> on #linux-sunxi ⠈⠳⣄⠀⠀⠀⠀
