From owner-freebsd-hackers Sat Apr 18 02:10:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA28750 for freebsd-hackers-outgoing; Sat, 18 Apr 1998 02:10:23 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA28739 for ; Sat, 18 Apr 1998 09:10:15 GMT (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id CAA24334; Sat, 18 Apr 1998 02:10:14 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd024326; Sat Apr 18 02:10:06 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id CAA10279; Sat, 18 Apr 1998 02:10:04 -0700 (MST) From: Terry Lambert Message-Id: <199804180910.CAA10279@usr01.primenet.com> Subject: Re: vnodes... To: edavis@nas.nasa.gov (Eric A. Davis) Date: Sat, 18 Apr 1998 09:10:04 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199804172302.QAA02261@shark.nas.nasa.gov> from "Eric A. Davis" at Apr 17, 98 04:02:03 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If I only have a pointer to a vnode, is there any way to get the > inode number of the intermediate (parent) directory? More specifically, > I am looking to do this in the vn_write (sys/kern/vfs_vnops.c) function. You can get the inode number for the vnode of the file. Then you can exhaustively search the inodes file system for a directory block containing a pointer to the inode. This will be the parent directory. If the inode has more than one link, this will be *a* parent directory. That is, there is more than one parent directory, and you can't know the parent directory that was the one that was used to open the inode in the first place. So if you are going to use this to implement inherited rights, or some other thing, like deleting an open file or renaming an open file to implement automatic log rolling, etc., you are out of luck. I have a design for a mechanism that would allow you to get this information, but your vnode use would go up dramatically, and it would require the use of the VM object aliases that are still a bit problematic for FS stacking, as is. Effectively, you would associate the parent directory of a file with the in-core vnode instance of the file by using a derived alias object. All VOP operations would be indirected through the container vnode to the real vnode. Alternately, if you just care about FFS, you could change the on disk structure of hard links to use an intermediate "alias" inode. You would have to change fsck, and you would have to handle boundry conditions, such as "deleting the second to last link from a file, which was the non-alias inode, so the alias inode has to become the real inode before the delete can be completed, and -- Whoops! I just crashed with two ''real'' inodes!", etc.. I implemented this once already (in SVR4.2 ES/MP back in 1993/1994) for NetWare Trustee Rights (which are reverse inherited) in an attributed UFS called NWFS. I also did resource forks and OS/2 extended attributes and kernel globbing and multiple namespaces and a bunch of other cool stuff. Too bad Novell bought USL during the BSDI/UCB lawsuit and shot to hell all Usenix interest in any papers from Novell/USG employees, or it would have been published. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message