On Mon, Nov 26, 2007 at 09:49:14PM +0100, Jim Meyering wrote: > Phillip Susi <[EMAIL PROTECTED]> wrote: > > Jim Meyering wrote: > >> Yes, it's expected, whenever you use a file system with > >> imperfect-by-definition inode emulation. > > > > AFAIR, the fat driver uses the starting cluster of the file as the > > inode number, so unless you defrag or something, it shouldn't change. > > Sorry, but no. > If only it were so easy. > The kernel maintains a limited-space cache for FAT inodes, > so the inode of "." at the beginning of a traversal will not > be the same as the inode reported for that same directory > after du/fts has traversed a tree that's large enough.
The real issue is that starting cluster won't work at all for empty files. IOW, ftruncate() would change st_ino; no-go for all kinds of obvious reasons. Now, one _could_ play games with separating inode numbers of directories and non-directories, but that causes too much PITA. What we have is a guaranteed "st_ino doesn't change for the lifetime of in-core inode", without any promise of persistence beyond that. Since way back - at least '99, IIRC. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
