Date: Thu, 18 Nov 1999 19:44:07 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: John Polstra <jdp@polstra.com>, robert+freebsd@cyrus.watson.org Cc: hackers@FreeBSD.ORG Subject: Re: Portable way to compare struct stat's? Message-ID: <v04210102b45a48b3b0aa@[128.113.24.47]> In-Reply-To: <199911181840.KAA03119@vashon.polstra.com> References: <Pine.BSF.3.96.991116103055.6960A-100000@fledge.watson.org> <199911181840.KAA03119@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. (here at RPI we have a lot of files in AFS space, and I've certainly seen problems because some application depended on that POSIX promise, but that POSIX promise is pretty meaningless in our real world. I would not want to encourage any programmer to depend on that, unless they are pretty much certain that the program will not have to deal with files from external file systems.) 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. --- 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?v04210102b45a48b3b0aa>