Re: [Re: Inodes]

["H. Peter Anvin" <hpa@transmeta.com>]

Alexander Viro wrote:
> 
> On Mon, 14 May 2001, Andreas Dilger wrote:
> 
> > Just to clarify, this means that the "inode numbers" reported by an
> > msdos filesystem are a function of the disk-layout itself (i.e. they
> > are determined at mount time), and not numbers created when the file
> > is first accessed (AFAIK).
> 
> Wrong. open file. rename() it to another directory. truncate it to
> zero. write to it. ->i_ino must have stayed they same. _Nothing_
> on-disk that would be related to that file had stayed the same.
> FAT simply doesn't allow inode numbers as functions of disk layout.
> 

Correct.  At least at one time it used the offset of the directory entry
when that particular inode was last "seen" by the kernel... meaning that
when it finally dropped out of the inode cache, it would change inode
numbers.  I thought that was a reasonable (by no means perfect, though)
solution to a very sticky problem.

iso9660 also uses the offset of the directory entry, but iso9660
obviously doesn't have the problem of modifications.  It also means the
inode number is different if you mount a disk with Joliet (but not
RockRidge) or not, since Joliet uses a separate directory hierarchy.

	-hpa  

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt