how can i get a file name knowing its descriptor?

[Matthew Dillon]

: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