Date: Thu, 3 Jul 2008 14:55:26 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@elischer.org> Cc: freebsd-hackers@freebsd.org, Uladzislau Rezki <v.rezkii@sam-solutions.net> Subject: Re: how can i get a file name knowing its descriptor? Message-ID: <200807032155.m63LtQwY092981@apollo.backplane.com> References: <200807031428.02286.v.rezkii@sam-solutions.net> <486D1497.3020206@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:well, not really, at least not the name by which it was looked up.
:you MIGHT (sometimes) be able to use the directory name cache to work
:it out.. At one stage it was possible to do this for some percentage
:of the files but I dont remember if it was possible in 4.x.
:
:the idea is that you can find the name and do '..' lookups in the name
:cache.. i.e. fid if there is a name with your inode number,
:then get the directory inode number from that and then look up ..
:with that inode number etc.etc. but:
:
:I dont remember if we store ".." in the name cache these days
:(I remember some movement on this over the years)
:and
:Not all of the path to root might be there..
:
:let me know if you work it out :-)
It's rather a mess. There are several parent directory linkages
but FreeBSD uses a non-deterministic namecache architecture so
sometimes it simply is not possible to backtrack the directory.
There are three major elements:
vp->v_dd is usually only populated for directory vnodes and not for
non-directory files so using it to traverse ".." from a non-directory
(aka from a file) generally will not work. It can be NULL (and quite
often is), even for a directory vnode if I remember right, typically
causing the caller to issue a VOP_LOOKUP() of "..".
The namecache structure has a nc_dvp field which can typically be
used at an end point (non-directory) to access the directory,
assuming you can locate the namecache structure associated with the
vnode you wish to construct the path for.
And there is vp->v_cache_dst which is a list of namecache
structures associated with the vnode, and vp->v_cache_src which
associates a directory vnode with a list of children (namecache
structures).
All three can be empty. It is usually possible to reconstruct the
path backwards if you can locate a directory vnode. Doing it
from a non-directory vnode is more problematic as you have to rely
on the existance of a cache linkage that gives you the directory,
and you can then work up the chain based on that.
VOP_LOOKUP() of ".." only works from a directory vnode.
--
It is possible to store more deterministic information, there is
really no underlying limitation to doing so other then NFS. It
requires passing all changes, such as renames and unlinks, through
the namecache instead of simply invalidating the namecache.
Once that is done each file pointer (struct file), and cdir, rdir, and
jdir in (struct filedesc), need an additional field which points
to a persistent namecache entry representing the file.
When you are vnode-relative you have no idea which namecache
entry the potentially hardlinked file was accessed through. If you
store the ncp reference separately, however, you know exactly which
namecache entry, and hence which path, the hardlinked file was
accessed through. Such a feature also makes implementation of
NULLFS style overlays ridiculously easy because you no longer need
to alias the vnode structure. When the vnode structure no longer
needs to be aliased all the related hacks to deal with aliased
vnode structures (such as accessing the related VM object, and special-
casing the locking) can also be ripped out.
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807032155.m63LtQwY092981>