From owner-freebsd-hackers Thu Dec 2 9:25:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 042CC14E00 for ; Thu, 2 Dec 1999 09:25:26 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id MAA23121; Thu, 2 Dec 1999 12:23:16 -0500 (EST) Reply-To: Randell Jesup To: Wes Peters , freebsd-hackers@freebsd.org Subject: Re: Portable way to compare struct stat's? From: Randell Jesup Date: 02 Dec 1999 12:25:43 -0500 In-Reply-To: Wes Peters's message of "Wed, 01 Dec 1999 12:04:13 -0700" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters writes: >Randell Jesup wrote: >> >> On a single system, if st_dev and st_ino are equal, you must be referring >> >> to the same object. If not, I'd like to hear about it. >> > >> >This assumption has always caused lots of pain and suffering for >> >distributed file system people -- in a distributed file system, the >> >requirement that you can generate a unique 32 bit number for each file or >> >directory visible in the FS is a fairly arduous one. Either the number is >> >> Too bad that the "that's the way it's always been done"/"inodes >> were handed down by God" arguments are so hard to overcome. 1/2 :-) > >Perhaps we simply need to expand the size of ino_t and carefully convert >smaller types to it in the stat call? It's the paradigm that's the problem here, not the implementation, IMHO. While expanding ino_t might allow us to kludge around the problem, the real issue is that not all filesystems have an easy way to associate a (semi)permanent, unique number of any size with a specific file. If it were long enough to store a path, that might solve some FS's problems, except that directories in the path might get renamed. Quite honestly, the application should not be determining whether two files are the same directly. The OS/FS should do that. ino_t in stat() should be deprecated and and alternative system call created. Programs that reference the inode field should be modified to use the new interface. Of course, if I were to believe this would happen just because it's the right design, I'd also believe in the tooth fairy. :-( There's lots of ancient cruft in the design of *nix systems that's very hard to get people to consider even touching, let alone deprecating or removing. Sigh. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message