Messages in this thread | | | Date | Sun, 17 Jan 1999 09:13:52 +1300 | From | Chris Wedgwood <> | Subject | Re: [RFC] What should we do with FAT inode numbers? |
| |
On Sat, Jan 16, 1999 at 12:45:10PM -0700, Colin Plumb wrote:
> Well, the usual Unix guarantee is that for the lifetime of a single > file, (device,inode) uniquely identifies it.
[...]
> 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?
I wrote some backup software that does hard-link detection, incremental updates (ie. detection of append files such as logs), and a whole bunch of other stuff.
It also detects the same file when they are not hard-linked, by making sha1 checksums of the files (obviously not every time).
When I extended this to work for other file-systems, I had to modify the code forgo any `shortcuts' that persistent inode numbers allow... this means I need knowledge of various file-systems properties.
Anyhow, the point is I think this is a user-space problem. Software which blindly assumes too much based upon inode number will break under certain circumstances... indeed, this does include qmail, sendmail and various other `mission' critical applications, but here the admins just have to have a clue....
-cw
- 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/
| |