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?
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
