Re: du: fts and vfat

[Al Viro]

On Mon, Nov 26, 2007 at 09:49:14PM +0100, Jim Meyering wrote:
> Phillip Susi <address@hidden> 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.