fdescfs brokenness

[Kostik Belousov]

On Thu, May 07, 2009 at 08:07:46PM -0700, Tim Kientzle wrote:
> Colin Percival recently pointed out some issues
> with tar and fdescfs.  Part of the problem
> here is tar; I need to rethink some of the
> traversal logic.
> 
> But fdescfs is really wonky:
> 
>  * This is a nit, but:  ls /dev/fd/18 should not
>    return EBADF; it should return ENOENT, just
>    like any other reference to a non-existent filename.
>    (Just because a filename reflects a file descriptor
>    does not mean it is a file descriptor.)
This is a traditional behaviour for fdescfs. According to man page,
open("dev/fd/N") shall be equivalent to fcntl(N, F_DUPFD, 0).
Solaris behaviour is the same.

> 
>  * The fairly routine recursive directory walker
>    below gets hung in fdescfs.  It appears that
>    the two opendir() invocations active at the
>    same time interfere with each other.
What you mean by "gets hung" ? In my limited testing, it works.
Opendir creates a new directory in /dir/fd by the mere fact of opening
the directory. So it walks into that dir, returning to step 1.

> 
>  * A similar chdir()-based version of the directory
>    walker below breaks badly; you can chdir() into
>    a directory under /dev/fd, but you can't chdir("..")
>    to get back out of it.  (This is the particular
>    problem that tar is running afoul of.)
Not sure about this one. I think that fdescfs vnodes do not support
lookup on anything not being root of the fdescfs.

> 
>  * Running "find /dev/fd" generates bogus ENOENT errors
>    because you can opendir() a directory inside of /dev/fd,
>    and read the entries, but you can't access those entries
>    because path searches don't work through fdescfs.
Again, this may be a consequence of the previous issue.

> 
> I think the right solution here is to add a VOP_ACCESS
> handler to fdescfs that bars all access to directory
> nodes under /dev/fd.  Basically, if your program has a
> directory open, that should be reflected as a directory
> node that you can't do anything with.  The current implementation
> allows you to chdir(), opendir(), etc, those directory
> nodes, but the machinery to fully support those operations
> is missing so they just screw things up.
This would chomp the fdescfs functionality, IMHO. Why directory
file descriptors should behave differently then any other file
descriptor ?

I think that the actual solution for the walker problems is to
ignore the synthetic filesystems altogether. The information is
provided by sysctl vfs.conflist (note that the output is binary),
see VFCF_* flags, esp. VFCF_SYNTHETIC. The flag is correctly
set at least by procfs, devfs and fdescfs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090508/6321e52c/attachment.pgp