At 6:56 PM -0800 11/18/99, John Polstra wrote:
>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.
Hmm. My guess is that we're talking about different aspects of
this issue. I believe I agree 100% with what you're saying here,
but I don't see how your comments apply to what I was saying.
That might mean I am just missing some important detail, so...
From an operating-system point of view, I think the POSIX
requirement is a good thing. Operating system developers
should do everything they can do to make sure that those two
fields will "uniquely identify the file within the system".
(what exactly is meant by "in the system" here? I'm assuming
it means all locally-attached hard drives...). I certainly do
not think that is an onerous request to make of operating
system developers.
From the application side of things (ie, a person writing a
generic program), I'm saying it is a fact that those two
numbers will not always "uniquely identify a file", mainly
because of distributed file systems (NFS-mounted, or AFS,
or whatever). I am stating a fact of the real world, and am
saying that "application developers should plan accordingly".
Example: it is a fact that if your system is using NFS to mount
filesystems exported from AIX boxes, then you can not depend on
those numbers. Two different processes (say, 'lpr' running as
a generic user, and 'lpd' running as root) will get DIFFERENT
values for those numbers, when stat()-ing the exact same file
on the exact same machine using the exact same path at the
same time. I'm not even trying to compare two different paths
to see if they point to the "same inode", I'm saying these two
numbers do not even identify the file, never mind "uniquely"
identify it.
It might be that freebsd does things which fix this behavior,
but that only helps if the application developer knows that
their application will only run on FreeBSD. The problem, as
I understand it, is in the way AIX *exports* the file systems.
Now, maybe your point is that AIX hasn't done it's homework
here, and that would be a good point. However, that does not
change the behavior an application developer will actually see,
and there is nothing the application developer can do to avoid
the consequences of that behavior.
That's one NFS-based example that's on my mind because I
recently tripped over it. I'm pretty sure there are specific
AFS-based examples too, but I can't think of one at the moment.
Probably issues with mounting the same volume at multiple
points within the AFS hierarchy. Perhaps it's just the sheer
number of files one can find in the entire hierarchy of AFS
is too many to uniquely identify them all in "such a small
field" as 'st_dev + st_ino'.
---
Garance Alistair Drosehn = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
