Date: Sat, 20 Nov 1999 15:15:40 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: John Polstra <jdp@polstra.com> Cc: hackers@FreeBSD.ORG Subject: Re: Portable way to compare struct stat's? Message-ID: <v04210103b45ca75a4e20@[128.113.24.47]> In-Reply-To: <XFMail.991118185611.jdp@polstra.com> References: <XFMail.991118185611.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute 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?v04210103b45ca75a4e20>