Date: Wed, 22 Mar 2000 03:30:05 -0800 (PST) From: Peter Edwards <peter.edwards@openet-telecom.com> To: freebsd-bugs@FreeBSD.org Subject: Re: Re: bin/17405: one more fstat patch Message-ID: <200003221130.DAA40035@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/17405; it has been noted by GNATS. From: Peter Edwards <peter.edwards@openet-telecom.com> To: bde@zeta.org.au Cc: freebsd-gnats-submit@FreeBSD.ORG, peter.edwards@ireland.com Subject: Re: Re: bin/17405: one more fstat patch Date: Wed, 22 Mar 2000 11:23:59 +0000 Hi, With getfname &ing 0xffff, and nfs_filestat() not doing it, you'll never find the filesystem for an NFS inode. I guess I picked adding one 0xffff rather than removing the rest, 'cause it seemed more likely the single omission was in error rather than the two or three uses of 0xffff. I suppose my bug is that the 0xffff is being applied inconsistently, while the quoted PR's bug is that the 0xffff is incorrect :) Is the 0xffff is some historical artifact, then? If someone removes the 0xffff's, a la bin/16320, be sure to catch the new ones in msdosfs.c and cd9660.c Cheers, Peter. ---- Begin Original Message ---- From: Bruce Evans <bde@zeta.org.au> Sent: Fri, 17 Mar 2000 03:31:46 +1100 (EST) To: peter.edwards@ireland.com CC: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: bin/17405: one more fstat patch On Thu, 16 Mar 2000 peter.edwards@ireland.com wrote: > >Description: > fstat "file", where file is on an NFS volume, is still broken. > The problem is that the fsid is made up of a type and a dev_t. > the nfs_filestat() doesn't drop the type (to produce a udev_t) by &ing > with 0xffff. All the other filesystem types do this already. This is backwards. &ing with 0xffff is a bug. The bug is fixed for ufs in PR 16320. Bruce ---- End Original Message ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003221130.DAA40035>