For example, Nethack save files store the inode number so they can't be
(easily) copied. Qmail uses the inode number to generate unique filenames.
Various backup and archive utilities use (device,inode) comparisons to
detect hard links.
Another reasonable, but perhals not as critical guarnatee, is that a file's
inode number not change while you have it open. This may seem obvious, but
perhaps it's a good thing to consider breaking, when ftruncate) and O_TRUNC
are used.
As people have pointed out, the first cluster of a file is a good unique
identifier. Too bad zero-length files exist.
Perhaps the best thing to use would be the first block number times K
when the file is non-zero in size, and the block number of the directory
entry times K plus the slot number within the block for empty files.
(K, of course, is the number of direcotry slots per block. Slots
are 32 bytes long, but I don't know about the block size.)
This is guaranteed unique because the first slot in each directory
(which is the directory's inode number) always contains ".", so it
won't be a zero-length file. (I think the root directory is magic,
but it can be special-cased.)
This means that zero-length files sort of have no identity. I'm not
too terribly worried about that. It also means that disk optimizers
will scramble *all* the inode numbers. I'm also not too worried about
that, either.
Truncated files, you see, are a problem. If you want to preserve inode
numbers, then just keep the first block allocated when you call O_TRUNC
or ftruncate(). (If you close the file when it's zero length, the block
gets freed and the inode number mutates then. But that's a less likely
scenario.)
Frankly, it's a hard problem. In VFAT, don't directory entries get
shuffled when they're renamed, in case the new long name requires more
slots to store than are available at the old location?
Still, it only affects zero-length files, and saying that zero-length
files are not necesarily distinguishable by inode number doesn't strike
me as too evil.
Does anyone have any better ideas?
-- -Colin- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/