> It just has other bugs... > > It assigns inode number 0 to all zero sized files > as fdar as I can see.
What do you know about that! I knew it was theoretically possible to assign the same inode number to two files, but I really didn't think it would happen for a common case. :-(
I never posted here my first attempt at altering the inode numbering scheme. It used a red-black tree to map a particular file to a particular inode number. I think it guaranteed unique inode numbers, I had to give up on it because it consumed too much memory.
I'm not even sure it's possible to guarantee unique inode numbers without some sort of map. For example, I just took a quick look at the NetBSD cd9660 file system. For non-directories, it appears to use the lower 32-bits of the byte offset of the directory record for the file as the inode number. For directories, it looks like it uses the same inode number I do except it shifts it left.
I know "ls" and "find" require each directory to have a unique inode number in order to recurse properly, and I think I provide this. On the other hand, the current linux code cannot provide this, and the NetBSD code appears to not provide this either. So, I think I'm making progress.
For non-directories, it's another story. I think I'm no better or worse than the current linux code or the NetBSD code. I'm o.k. with it (for now) because I just don't know of any commonly used programs that might break. So for now, I'm willing to make the trade off of low kernel memory consumption for having non-unique inode numbers for zero-length files.
Don't get me wrong, I'd be happy to rewrite things to guarantee unique inode numbers if someone else can put forward how to proceed.
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
