[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fakeroot problem

From: Marcus Brinkmann
Subject: Re: fakeroot problem
Date: Sat, 11 May 2002 05:12:15 +0200
User-agent: Mutt/1.3.28i

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

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).


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]