fsck.fat does not repair badly named file called .. or .

[seanyoung]

Files called . or .. are not accessible on linux, since those filenames are hardcoded in the kernel as path walks.

[root@xywoleh ~]# fsck.vfat -l /dev/loop0p1 
fsck.fat 4.2 (2021-01-31)
Checking file /System Volume Information (SYSTEM~1)
Checking file /$RECYCLE.BIN
Checking file /FOO
Checking file /System Volume Information/WPSettings.dat (WPSETT~1.DAT)
Checking file /System Volume Information/IndexerVolumeGuid (INDEXE~1)
Checking file /$RECYCLE.BIN/DESKTOP.INI
Checking file /FOO/.. (C59D~1)
/dev/loop0p1: 7 files, 7/15815 clusters

I can provide disk image if anyone is interested.

[pali]

Can you explain what is the issue?

[seanyoung]

There is a regular file /FOO/.. which contains Hello, World!. So if I try to mount the filesystem and cat it, it does not work.

[root@xywoleh tmp]# losetup -P /dev/loop0 floppy.img 
[root@xywoleh tmp]# mount /dev/loop0
loop0    loop0p1  
[root@xywoleh tmp]# mount /dev/loop0p1 /mnt
[root@xywoleh tmp]# cd /mnt/FOO
[root@xywoleh FOO]# ls -la
total 34
drwxr-xr-x. 2 root root  2048 Sep 27 12:51 .
drwxr-xr-x. 5 root root 16384 Jan  1  1970 ..
drwxr-xr-x. 5 root root 16384 Jan  1  1970 ..
[root@xywoleh FOO]# cat ..
cat: ..: Is a directory

The file .. needs to be given another name or it is in-accessible.

[pali]

Ok, now I see, this is for sure error.

Are you able to provide that broken disk image dump? You should be able to upload packed disk image into .gz or .zip file archive directly to this github issue.

[seanyoung]

floppy.img.gz

I discovered this while investigating rust-lang/rust#89270 (comment)

[pali]

Microsoft fatgen103.doc specification says:

Short Directory Entries
Short names are limited to 8 characters followed by an optional period (.) and extension of up to 3 characters. The total path length of a short name cannot exceed 80 characters (64 char path + 3 drive letter + 12 for 8.3 name + NUL) including the trailing NUL. The characters may be any combination of letters, digits, or characters with code point values greater than 127. The following special characters are also allowed:

$ % ' - _ @ ~ ` ! ( ) { } ^ # &

Names are stored in a short directory entry in the OEM code page that the system is configured for at the time the directory entry is created. Short directory entries remain in OEM for compatibility with previous versions of MS-DOS/Windows. OEM characters are single 8-bit characters or can be DBCS character pairs for certain code pages.

Long Directory Entries
Long names are limited to 255 characters, not including the trailing NUL. The total path length of a long name cannot exceed 260 characters, including the trailing NUL. The characters may be any combination of those defined for short names with the addition of the period (.) character used multiple times within the long name. A space is also a valid character in a long name as it always has been for a short name. However, in short names it typically is not used. The following six special characters are now allowed in a long name. They are not legal in a short name.

+ , ; = [ ]

I understand it as that . and .. file names are allowed as long name, but not as short name.

In your example you have file which has long name .. and short name C59D~1.

[seanyoung]

The short name is randomly generated, and bares no resemblance to the file name originally created. However, as you point out, it does have the advantage of being a valid file name.

[seanyoung]

@pali are you suggesting that mks.fat should leave . and .. long names as is?

[pali]

Ehm? mkfs.fat should erase everything which is stored on existing filesystem.

[seanyoung]

Sorry, I meant fsck.fat.

[pali]

Hm... I'm not sure. . and .. are strange file names. I would wait how kernel fs maintainers decide what to do with these filenames. And then implement compatible behavior into fsck.fat.

[seanyoung]

I agree. It can be argued both ways:

• Windows allows . and .. files to be created and these are not invalid file names according to the spec
• Files called . and .. is madness

[pali]

For vfat.ko there is already uni_xlate mount option and maybe this is the intended way how linux kernel expose these problematic filenames into vfs... just there is missing check that . and .. are problematic too.

[seanyoung]

That seems very reasonable. It might be helpful to send a patch to the list to get the conversation going.