🚀 go-pugleaf

Submitted-by: jason@cnd.hp.com (Jason Zions)

Dominic Dunlop says:

> I dare say that, as more types of object appear in filename space (and
> I, for one, should like to see them do so), the question of determining
> uniqueness will become knottier.  Suppose, for example, that one used
> filenames as handles for virtual circuits across a wide-area network.
> Conceivably, the number of such circuits could be sufficiently large
> that it will become difficult o shoe-horn a unique identifier into the
> existing stat structure fields.  A problem for the future?

Actually, a problem for today. P1003.8 has to cope with the fact that a
local file for major 0, minor 0x010100, inode 1234 is *different* from a
file on some remote machine with the same (major,minor,inode) triplet. But
adding a new field or fields to the stat structure isn't gonna work;
expanding that structure will cause many implementations to shatter (i.e.
break spectacularly). Just cobbling up a major number for some random
remotely-mounted filesystem is unsatisfactory, unless the cobble is
persistant over umount/mount operations. (An application starts to run;
opens file1 on remsys, gets (maj,min,ino). Network goes down, comes up;
system remounts remsys. App opens file2 on remsys. That major number had
better be the same for remsys!)

What's needed is a simple routine which can be called to determine if two
handles point to the same object. It would be nice if there was a routine
which took as arguments a file handle and a path name and returned true iff
the path referred to the same file. This routine would be guaranteed by the
implementor to work for any file-system resident object provided for; e.g.
an SVR4 implementation would have to be able to tell if a file opened via
RFS referred to the same underlying file as one opened under NFS.

I don't know if that's sufficient, though; application programmers may be
using the stat info for other purposes, and a remote_addr field might be a
good idea. Once P1003.12 decides on a representation for an arbitrary
network address, which might be considerably larger than an IP address.

Jason Zions

Volume-Number: Volume 21, Number 174