lkml.org 
[lkml]   [1999]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

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