Date: 02 Dec 1999 12:25:43 -0500 From: Randell Jesup <rjesup@wgate.com> To: Wes Peters <wes@softweyr.com>, freebsd-hackers@freebsd.org Subject: Re: Portable way to compare struct stat's? Message-ID: <ybuln7di7ag.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Wes Peters's message of "Wed, 01 Dec 1999 12:04:13 -0700"
next in thread | raw e-mail | index | archive | help
Wes Peters <wes@softweyr.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybuln7di7ag.fsf>