Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > What exactly would the problem be there? Maybe I've missed a beat
> > in the conversation.
>
> Maybe I am overlooking something, I am not that familiar with
> libdiskfs.
>
> My question is: given the situation that dir_lookup is called to
> re-open a node, which is a symbolic link, the target that link points
> to has to be read out and needs to be resolved.
>
> Reading out the link target is not a problem, but how should the path
> name resolving process continue without a start directory?
Oh, that. Blech blech blech.
And, of course, this matters in just this case! Because it's a union,
and so the node is found in *two* directories and it's not at all
clear which one is right.
Ok, so that explains why the code is as it is. The problem isn't
specific to relative symlinks; translator interchange also needs to
know what ".." is supposed to mean--which is the same "parent
directory" as for the relative symlink case.
So ignore what I said before; here is some new excogitation:
Assuming we want ".." to go to the *union*, then the union filesystem
should be doing translator startup itself. This would work as
follows:
Union fs opens the node with O_NOTRANS and no permissions.
If it's a translator (of any kind, including symlink) then it
does the translator linkage *itself*, just as diskfs/netfs does it.
If it's not a translator, then it returns it to the user with
FS_RETRY_REAUTH.
[Note that in the translated case, it will ultimately end up doing a
reauth as well.]
Assuming we want ".." *not* to go to the union, then the union
filesystem has a race condition, I think, as you had earlier noted,
because it will be looking it up, and then doing a retry to tell the
user to look up the file in its "real" directory.
Because of this difficulty, I think clearly (heh heh) the right thing
is the first case.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
