[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: du: fts and vfat
From: |
Al Viro |
Subject: |
Re: du: fts and vfat |
Date: |
Mon, 26 Nov 2007 21:20:50 +0000 |
User-agent: |
Mutt/1.4.1i |
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.