Date: Mon, 5 Sep 2005 18:00:56 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Sergey Uvarov <uvarovsl@mail.pnpi.spb.ru> Cc: freebsd-hackers@freebsd.org Subject: Re: vn_fullpath() again Message-ID: <20050905175709.H88940@fledge.watson.org> In-Reply-To: <431C4D90.2010602@mail.pnpi.spb.ru> References: <431C4D90.2010602@mail.pnpi.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050905175709.H88940>