Incorrect handling of . and .. files

From: Sean Young
Date: Mon Sep 27 2021 - 07:19:55 EST


Hi,

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.

This is what I did on Windows using rust:

use std::fs::File;
use std::io::Write;

fn main() {
let mut file =
File::create(r"\\?\D:\..").expect("create dot file");
file.write_all(b"Hello, world!").expect("write dot file");
}

Now on Linux (I also created a file called ".").

[root@xywoleh tmp]# mount -t exfat /dev/loop0p1 /mnt
[root@xywoleh tmp]# cd /mnt
[root@xywoleh mnt]# ls -la
total 20
drwxr-xr-x. 5 root root 4096 Sep 27 11:47 .
drwxr-xr-x. 5 root root 4096 Sep 27 11:47 .
dr-xr-xr-x. 1 root root 176 Sep 21 11:05 ..
dr-xr-xr-x. 1 root root 176 Sep 21 11:05 ..
drwxr-xr-x. 2 root root 4096 Sep 27 2021 '$RECYCLE.BIN'
drwxr-xr-x. 2 root root 4096 Sep 27 2021 'System Volume Information'

Microsoft says this:

https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces

Because it turns off automatic expansion of the path string, the
"\\?\" prefix also allows the use of ".." and "." in the path names,
which can be useful if you are attempting to perform operations on a
file with these otherwise reserved relative path specifiers as part of
the fully qualified path.

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.

Thanks,
Sean