From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 5 17:00:57 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED59E16A41F for ; Mon, 5 Sep 2005 17:00:57 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4073843D45 for ; Mon, 5 Sep 2005 17:00:57 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id CE66C46B09; Mon, 5 Sep 2005 13:00:56 -0400 (EDT) Date: Mon, 5 Sep 2005 18:00:56 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sergey Uvarov In-Reply-To: <431C4D90.2010602@mail.pnpi.spb.ru> Message-ID: <20050905175709.H88940@fledge.watson.org> References: <431C4D90.2010602@mail.pnpi.spb.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: vn_fullpath() again X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2005 17:00:58 -0000 On Mon, 5 Sep 2005, Sergey Uvarov wrote: > all knows that vn_fullpath() is unreliable. However I really need to get > a filename for a given vnode. To simplify the task, I do not care of > synthetic file systems or hardlinks. > > I have looked through archives in hope to find a better solution. It > seems that linux_getcwd() approach could help. However to make that code > work for me, I need to know a directory vnode where the file resides. > vnode->v_dd field looks promising. But as I understand it did not help > if file name is not in a name cache. > > So the question: is it ever possible to get directory vnode for a given > file vnode? One way to look at the problem is from the perspective of how you might derive that information from an on-disk inode. If you look at the UFS layout on-disk, you'll see that there is no pointer to a directory back from a leaf inode; in kernel, you can have a reference to a vnode with no back pointer to a directory vnode. In order to find the parent, you potentially have to iterate through all directories on the hard disk looking for the parent, which is a potentially long-running activity. It's also not at all theoretical: vnodes are often accessed without any path lookup at all. For example, background fsck may pull inodes off disk without a name lookup, and the NFS server can receive file handle references following a reboot from a live client that maintains cached references -- it will service them without performing a lookup. So unfortunately, the answer is complex: (a) you may have to search the disk for a name, and (b) you may not even find one, since there can be files without any name at all (i.e., a temporary file that has been unlinked). On non-UFS style file systems, such as HFS+, it is possible to generate a path from the file system root without extensive disk I/O. However, all common UNIX-like file systems don't have this property -- Sun's version of UFS, ext2fs/ext3fs, and so on. If the child vnode is a directory, you can just follow it's '..' link or covered vnode, of course... Robert N M Watson