[lkml]   [2003]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:32    [W:0.106 / U:5.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site