[U-Boot] FAT filesystems and mtools-created filesystems

[Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>]

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?