Messages in this thread | | | Date | Wed, 05 Feb 2003 11:41:42 -0800 | From | "H. Peter Anvin" <> | Subject | Re: isofs hardlink bug (inode numbers different) |
| |
Kasper Dupont wrote: >> >>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? >
We have no idea, and we will never be able to know. They certainly *CAN*... they are just anonymous 32-bit values.
> >>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?)
Theoretically yes.
> 2) Do we need a way to find metadata from the inode number?
Currently we do, but we could rewrite the code not to.
-hpa
- 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/
| |