>On Wed, Aug 06, 2008 at 09:11:08PM +0300, Sergiu Ivanov wrote:
>> On Wed, Aug 6, 2008 at 7:53 PM, <
olafBuddenhagen@gmx.net> wrote:
> > That's why I wonder whether we should do the further lookup in
> > nsmux, or just let the client continue.
> >
> > I'm not sure about the exact implications. I think one case where
> > there would be a difference is when the client does a lookup with
> > O_NOTRANS... And I'm not sure which variant behaves more correcly in
> > this case. This needs some consideration.
> >
>
> It somehow seems to me that doing the further lookup in nsmux will be
> more appropriate...
Well, it's really impossible to tell for sure without considering all
corner cases...
Intuitively, I'd also go for that variant first I think; but it can very
well turn out later that the other is more logical...
I think I'll stick with this (first) variant for now. One of the
reasons for such a choice is that this implementation should require
less modifications to the standard code of netfs_S_dir_lookup. I'll
however try to consider the other variant in the meantime and if I
discover that this one will be more suitable, I'll tell you immediately.
> The situation about starting the translator could possibly be handled
> similarly to the way netfs_S_dir_lookup handles symlinks. In case a
> symlink is found, whose target is stated as a relative path,
> netfs_S_dir_lookup just prepends the already existent path with the
> path to the target of the symlink.
Not sure what you mean here.
What I wanted to say was that netfs_S_dir_lookup does not give the
client retry notifications in case it encounters a symlink (except for
the special case when the path is absolute), and symlinks are
translators. Probably, we shouldn't return retry notifications either
in case we encounter translators...
> It gives the client a retry notification only when the path to the
> target of the symlink is absolute.
Interesting. Why the distinction?
When the path to the target of the symlink is specified in absolute
form, netfs_S_dir_lookup gives the client the FS_RETRY_MAGICAL
notification and the client has to retry the lookup starting from
*their* root directory. I think this is the reason. At least this is
what I can deduce from the description of FS_RETRY_MAGICAL in
hurd/hurd_types.h.
> We should probably follow a similar idea, what do you think?
I don't see the parallel yet, so I can't say...