Date: Sat, 4 Dec 1999 15:17:29 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Assar Westerlund <assar@sics.se> Cc: Garance A Drosihn <drosih@rpi.edu>, Wes Peters <wes@softweyr.com>, Randell Jesup <rjesup@wgate.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Portable way to compare struct stat's? Message-ID: <Pine.BSF.3.96.991204151159.765A-100000@fledge.watson.org> In-Reply-To: <5lwvqu7as2.fsf@foo.sics.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Dec 1999, Assar Westerlund wrote: > Garance A Drosihn <drosih@rpi.edu> writes: > > In the case of AFS, I think you'd want to expand the size of st_dev. > > All files in an AFS volume are "one device", I would think. If the > > "device" is gone (ie, the volume is not mounted), then all files in > > that "device" (volume) will not be available. > > I'm confused. Did you mean `st_ino' there? I agree that you want to > see the whole AFS space as a single device. I agree. > > I don't know what would be best for other distributed file systems, > > though. Maybe both variables would have to increase in size. Maybe > > we should start by creating an "fcompare()" routine, which you'd > > pass two file descriptors to and it would say if they're the same > > file. Initially that routine could just do two fstat()'s, and > > compare st_dev and st_ino. We could then expand it to do better > > comparisons for other file-systems. > > In solaris there's a vnode operation vop_cmp that does exactly that. > But it's not exported to userland in any way. The suggested fcompare() would be a much better way for tar (and other programs with a "samefile" requirement) to identify objects that are the same, rather than relying on the device and inode numbers, which are fairly artificial constructions on a number of file systems--backing it with a vop_cmp(struct vnode *vp1, struct vnode *vp2, ...) would probably be the way to go--you'd probably ask the first vnode (and hence its supporting file system) if it was the same as the second vnode, so as to try and avoid aliasing issues (?). This places responsibility for maintaining information about file system objects back in the hands of the file system, where it probably should have been in the first place. The inode number in stat + posix semantics requirements essentially consist of requiring an unlimited size cache with no callback mechanism :-). They also resemble requiring an entire second namespace for each file system -- the vnode-happy namei() lookup namespace, and also an inode namespace. It's arguable that only the string-based namespace is broadly used, and consistent with the generalized VFS file system concept. The inode-number in stat is a hanger-on from the days of only UFS/NFS, and inappropriate in a VFS. That isn't to say that there should be a vop_get_fsspecific(struct *vp, struct something *something) to retrieve this for processes interested, just that it's not supposed to have cross-fs guarantees. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services 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?Pine.BSF.3.96.991204151159.765A-100000>