name cache (was Re[4]: vn_fullpath())

Igor Shmukler shmukler at mail.ru
Sun Mar 27 05:05:23 PST 2005


Hi,

Sorry for reopening an old thread. I am doing this because last time around I was 
unaware of some issues.

There are more corner cases/issues with vn_fullpath() and possibly the name cache.
Please correct me if I am wrong. Perhaps, I would even personally look into fixing 
these, but I would like to know everyone agrees that this is needed.

1. vn_fullpath() does not return names for VCHR vnodes. I think it would be handy if 
this was possible.
2. It appears that vn_fullpath() has problems with FD 0..2. [It even seems to happen 
regardless whether file descriptors were inherited or open via $foo >my.file]

I am under the impression that Linux d_path() does these things. Is there an 
agreement that this a problem and it would be benefitial to have vn_fullpath() [and 
name cache] behave in a "proper" way?

Where does dragonfly stand on this?

Thank you,

Igor

> :I seem to recall that DragonFly keeps the intermediate nodes.
> 
>     There's no way to backport that, it would be hundreds of man hours of
>     work.  DragonFly uses a totally different namecache topology now, one
>     that is mandatory and which guarentees the existance of intermediate
>     nodes.
> 
>     You'd have to implement something similar to libc's getcwd code.  e.g.
>     ".." through and scan each directory to find the matching inode if
>     the namecache entry is not present.  It actually wouldn't be too hard
>     to do.  It wouldn't be efficient, but vn_fullpath() is rarely used
>     so it shouldn't be a problem.



More information about the freebsd-hackers mailing list