On Monday 13 December 2021 12:39:03 Pali Rohár wrote: > On Monday 13 December 2021 07:47:44 Adam Borowski wrote: > > 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. > > That is truth. But question is what should do fsck tools with such file > names on filesystems where "." and ".." are permitted? Fully valid > argument is "do not touch them" because there is nothing bad with these > names. > > > > > 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. > > vfat has already own escaping scheme and it is documented in mount(8) > manpage. Invalid characters are translated either to fixed char '?' or > to ':'... esc sequence if uni_xlate mount option is used. But it looks > like that that kernel vfat driver do not have these two entries "." and > ".." in its blacklist. > > And, another important thing about vfat is that it has two file names > for each file. One short 8.3 and one long vfat. Short 8.3 do not allow > "." or "..", so another possibility how to handle this issue for vfat is > to show short 8.3 name in VFS when long is invalid. > > For UDF case, specification already says how to handle problematic > file names, so I think that udf.ko could implement it according to > specification. > > But for all other filesystems it is needed to do something ideally on > VFS layer. > > What about generating some deterministic / predicable file names which > will not conflict with other file names in current directory for these > problematic files? PING? Any opinion how to handle this issue? For VFAT this is still open question. > > 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. > > Namjae Jeon, would you be able to implement fixing of such filenames in > fsck.exfat tool? > > > > > Meow! > > -- > > ⢀⣴⠾⠻⢶⣦⠀ > > ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. > > ⢿⡄⠘⠷⠚⠋⠀ -- <willmore> on #linux-sunxi > > ⠈⠳⣄⠀⠀⠀⠀
