Garance A Drosihn wrote:
> At 10:40 AM -0800 11/18/99, John Polstra wrote:
>>I don't dispute that point, but it is worth mentioning that POSIX
>>specifically guarantees that st_dev and st_ino "taken together
>>uniquely identify the file within the system." So it is OK for
>>applications to rely on that.
>
> Given how many people have files mounted from foreign file systems,
> I would think that applications should not rely on that. Sure, it's
> a nice guarantee for a completely stand-alone system, but a "general
> purpose" application should consider that it may be dealing with
> files in NFS, AFS, or some other file system, and plan accordingly.
We must be interpreting the requirement differently, because it
doesn't seem onerous at all to me. The st_dev value needn't be the
same on two different hosts which both mount the same filesystem. I
also doubt that the requirement has to hold across remounts. Under
that interpretation, it's simple to meet the requirement. Just create
a locally-unique st_dev value whenever you mount a filesystem, and
if the filesystem is remote then record a mapping between (remote
hostname, remote host's idea of the "device") and the local st_dev
value. (I've never used AFS, so I may be missing something crucial
here.)
> If the program is only for you in your organization, then the
> POSIX promise is helpful. If you're sending the code off to "the
> world", then you should not rely on that posix promise. Just my own
> opinion, of course.
Well, the POSIX requirement isn't optional. If a system doesn't
meet it then it is not POSIX-compliant. So any application that is
targeted toward POSIX systems is perfectly within its rights to rely
on the requirement.
John
---
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc. Seattle, Washington USA
"No matter how cynical I get, I just can't keep up." -- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
