Hello, On Fri, Aug 8, 2008 at 2:13 AM, <[EMAIL PROTECTED]> wrote: > >On Wed, Aug 06, 2008 at 09:11:08PM +0300, Sergiu Ivanov wrote: > >> On Wed, Aug 6, 2008 at 7:53 PM, <[EMAIL PROTECTED]> 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... > I hope I managed now to explain to you what I mean :-) scolobb