On Sat, Sep 23, 2017 at 01:26:38PM +0300, Tuomas Tynkkynen wrote: > 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?
Reality triumphs over specification. Please submit a patch to fix the new problem. Bonus points if you can add an fs test for this case to test/fs/, thanks! -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
