Messages in this thread |  | | Date | Wed, 05 Feb 2003 12:30:36 +0100 | From | Kasper Dupont <> | Subject | Re: isofs hardlink bug (inode numbers different) |
| |
"H. Peter Anvin" wrote: > > There are inode numbers stored in RockRidge attributes, but using them > comes with some humongous caveats: > > First: You have absolutely no guarantee that they are actually > unique. Broken software could easily have written them with all > zeroes.
Maybe we can detect some of the cases with broken software, and at least provide an option to turn the RockRidge inode numbers off.
> > Second: If there are files on the CD-ROM *without* RockRidge > attributes, you can get collisions with the synthesized inode numbers > for non-RR files.
That can easily be solved. RockRidge inode numbers are multiplied by two, and synthesized inode numbers are all odd. Of course if the multiplication overflows a fallback to synthesized inode numbers would be necesarry. Does any software produce inode numbers large enough to make this a problem?
> > Third: If you actually rely on inode numbers to be able to find your > files, like most versions of Unix including old (but not current) > versions of Linux, then they are completely meaningless.
Agreed.
> > There is another way to generate consistent inodes for hard links, > which is to use the data block pointer as the "inode number." This, > however, has the problem that *ALL* zero-lenght files become "hard > links" to each other.
That problem can easily be solved. Simply use different methods for zero-length files and all other files. But there might be other problems with such an approach:
1) Could two different files have same data block pointer? (different sizes perhaps?) 2) Do we need a way to find metadata from the inode number?
-- Kasper Dupont -- der bruger for meget tid på usenet. For sending spam use mailto:aaarep@daimi.au.dk for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_); - 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/
|  |