On Sat, May 11, 2002 at 01:51:36AM +0200, Marcus Brinkmann wrote: > Maybe the way netfs_root_node is looked up in the passive translator case is > screwed? I set a breakpoint at netfs_demuxer, and a "chdir fakeroot-test" > gave me three fsys_getroot RPC in sequence before it failed with ENOTDIR. > And when following the call, it seems it ended up calling fshelp_fetch_root > on the "transbox" whatever that again is.
This is indeed what happens, here in more detail: netfs_root_node is set up with ->nn->file being the underlying node, when the translator starts up. A subsequent lookup starts with trying to get the root node of the translator with fsys_getroot. This, in netfs_S_fsys_getroot, first validates the stat information (fakeroot gets it from the underlying node directly, because there is no faked information yet). Then it checks if the node has a passive translator, or a running translator, and the lookup is done without O_NOTRANS. Which is the case here, because the underlying node of the translator has a passive translator setting. This makes netfs try to start up the translator by calling fshelp_fetch_root. Which fails with EOPNOTSUPP because we don't implement the get and set translator callbacks, which default to this error. We can say: luckily, because otherwise we would probably infinitely recurse over starting fakeroot translators. ;) The error is further clouded by the fact that glibc translates an EOPNOTSUPP error at dir_lookup into an ENOTDIR in lookup_error (libc/hurd/lookup-retry.c). A simple solution seems to be simply clear the translator flags of the root node in netfs_validate_stat. Also, at some point we might want to implement the _translator callbacks (again, maybe except for the root dir). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
