On Thu, Mar 16, 2000 at 12:31:00PM +0100, Olaf Kirch wrote:
[..]
> 1. There are various standards out there that very much like
> "inode numbers" to be unique. Tools like tar will barf badly
> if they're not. Whether they're supposed to be stable is a
> different issue. Whether they are supposed to be just
> 32 bit is also an entirely different issue.
Is there any chance of getting an API for user space that works in terms of
opaque keys of variable lengths, rather than inode numbers? It's a shame
something like this wasn't considered by however came up with the stat64, etc.
set of functions. Unfortunately glibc.info says ino_t has to be an arithmetic
type, so I can't see a way to do such a thing without extending the API. We
might even be able to satisfy the open-by-inode people with something like
this - or are there other problems with that?
--
"For example, after I took the screenshot of myself being
attacked by csh, csh was shot by friendly fire from behind,
possibly by tcsh or xv, and my session was abruptly terminated."
<URL:http://www.cs.unm.edu/~dlchao/flake/doom>
-
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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:20 EST