From owner-freebsd-hackers Sat Apr 18 09:56:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA17519 for freebsd-hackers-outgoing; Sat, 18 Apr 1998 09:56:27 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles306.castles.com [208.214.167.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA17480 for ; Sat, 18 Apr 1998 16:56:16 GMT (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id JAA04985; Sat, 18 Apr 1998 09:53:36 -0700 (PDT) Message-Id: <199804181653.JAA04985@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: edavis@nas.nasa.gov (Eric A. Davis), hackers@FreeBSD.ORG Subject: Re: vnodes... In-reply-to: Your message of "Sat, 18 Apr 1998 09:10:04 -0000." <199804180910.CAA10279@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Apr 1998 09:53:35 -0700 From: Mike Smith 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. Then there's the case where the file has been relinked between when it's been opened and the search, or where it's been unlinked in the same period. > 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. Yup. > 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. Yecch. Simpler just to store the full path used to open the file (presuming it was opened thus) with the vnode. This still gives lots of potential loopholes for the sort of administrative tool I would expect this to be used for (per-directory quotas, eg.) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message