Path: utzoo!attcan!uunet!cs.utexas.edu!jsq From: jason@cnd.hp.com (Jason Zions) Newsgroups: comp.std.unix Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions Message-ID: <13142@cs.utexas.edu> Date: 3 Oct 90 15:46:12 GMT Sender: jsq@cs.utexas.edu Organization: Hewlett Packard, Information Networks Group Lines: 40 Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman) Subject-References: <13132@cs.utexas.edu> <13135@cs.utexas.edu> X-Submissions: std-unix@uunet.uu.net 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