> o FAT now uses cluster numbering for inode info
It doesn't. It generates inumbers on the fly. Cluster numbering is
unusable for that - truncate() *shouldn't* change inumber. FAT *has* no
file invariants that would survive (a) rename, (b) truncate(), (c) write
and (d) umount. Of all those umount give the least pain wrt races. New
code guarantees constant inumbers for opened files.
The bottom line - inumbers on FAT will suck anyway. There is no
inodes in normal sense. And inumbers changing after reboot are *much*
better than exploitable races. On FAT usage of (old) inumbers for any
backup stuff was broken - rename() would go unnoticed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/