Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 27 Sep 2021 12:19:48 +0100
From:   Sean Young <sean@mess.org>
To:     Namjae Jeon <linkinjeon@kernel.org>,
        Sungjong Seo <sj1557.seo@samsung.com>
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Incorrect handling of . and .. files
Message-ID: <20210927111948.GA16257@gofer.mess.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

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