Hi,
FAT file systems created by GNU mtools have a problem that mtools doesn't initialize the first cluster field of the '.' and '..' directory entries. That is, with the following script:
mkdir fattmp cd fattmp mkdir -p foo/bar/baz touch foo/bar/baz/biff truncate -s 16M ../fattest.img mkfs.vfat ../fattest.img mcopy -bpsvm -i ../fattest.img ./* ::
... `fsck.vfat ../fattest.img` outputs:
/FOO/BAR/. Start (0) does not point to parent (3) /FOO/BAR/.. Start (0) does not point to .. (4) /FOO/BAR/BAZ/. Start (0) does not point to parent (2) /FOO/BAR/BAZ/.. Start (0) does not point to .. (3)
Now that's of course a bug in mtools, but the tricky thing is that Linux is fine with that (and probably Windows as well, or they would have drowned in complaints), presumably due to both OSes resolving '.' and ''..' in their VFS layers.
I'm not sure if this problem has always been there but I've started to see "Invalid FAT entry" prints lately, presumably since the "fat/fs: convert to directory iterators" change. In my case it accidentally works anyway, since I have an entry like 'LINUX ../foo/bar' in extlinux/extlinux.conf and an invalid FAT entry somehow makes it back to the root directory.
So should we
1) Ignore the problem and call mtools broken 2) Hack around this in the FAT driver 3) Special-case '.' and '..' in the common directory traversal code?