From owner-freebsd-bugs Wed Mar 22 3:30: 9 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id E8FA537C2F4 for ; Wed, 22 Mar 2000 03:30:05 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id DAA40035; Wed, 22 Mar 2000 03:30:05 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Wed, 22 Mar 2000 03:30:05 -0800 (PST) Message-Id: <200003221130.DAA40035@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Peter Edwards Subject: Re: Re: bin/17405: one more fstat patch Reply-To: Peter Edwards Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/17405; it has been noted by GNATS. From: Peter Edwards 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 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