Re: Unionfs, looking up links and translators

[Moritz Schulte]

tb@becket.net (Thomas Bushnell, BSG) writes:

> What we really want is for the user to do a retry of the name as it
> exists in the "real" location, and then if that results in ENOENT,
> we want the user to return back to the filesystem for another name
> to try.

Well, here you are only considering the ENOENT case.  But the node,
which is to be looked up, can change in different ways during the
lookup process, it can not only vanish (in which case the special
handling for ENOENT makes sense).  Specifically I am thinking of the
following problem:

After I did the O_NOTRANS lookup in unionfs, I check if the resulting
node is the same as the one returned by netfs_startup.  If it is, I
return ELOOP to make it impossible to reach the unionfs inside of the
unionfs again, which would lead to infinite recursion.  If it is not,
the lookup process continues (i.e.: returning retry information to the
user).

When unionfs returns a retry port to the containing, real directory
and a retry name, it is possible that whatever translator is installed
on the node; the race would still be there, although the user wouldn't
receive ENOENT.

                moritz
-- 
moritz@duesseldorf.ccc.de - http://duesseldorf.ccc.de/~moritz/
GPG fingerprint = 3A14 3923 15BE FD57 FC06  B501 0841 2D7B 6F98 4199