Messages in this thread | | | Date | Mon, 14 May 2001 14:18:08 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [Re: Inodes] |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |