From: "Steve Dodd" <steved@loth.demon.co.uk>
>
> 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.
I think we have 2 completely independant problems:
a) POSIX inode numbers [ino_t].
They must be unique, and programs such as tar uses them to identify the
target of hardlinks. It's currently 32-bits on i386, mips, mips64; 64-bits
on ia64, sparc64.
We don't support lookups based on ino_t, and we don't need it for NFS.
b) the ability to find an disk entry given a "key".
required for NfsV2, NfsV3.
This key should remain stable across rename, chown, reboot, .., and it
should never be reused for another file.
The key is quite long [NfsV2: 32 bytes, but several bits are required to
identify the superblock, optimizations]
I have no real idea how to solve that problem, I'm stuck with hardlinks:
/fs: mount point for a filesystem.
/fs/exported/
/fs/not-exported/: 2 folders
<local user>:
cp /bin/sh /fs/exported/f1
<nfsd gets a filehandle to f1>
<local user>:
mv /fs/exported/f1 /fs/not-exported/
(* what happens to the nfs file handle? still valid, or EACCES?*)
ln /fs/not-exported/f1 /fs/exported/f2
(* what now? Does it become valid again?*)
> We
> might even be able to satisfy the open-by-inode people with something like
> this - or are there other problems with that?
Who needs "open-by-inode"?
--
Manfred
-
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:24 EST