The intent of fakeroot is to be unaware of translators in the underlying directory tree. That is, to use the translated nodes transparently; that's why its lookups don't use O_NOTRANS. If you think about it, that's the only thing that really makes sense for a translator applied to whole directory trees that are ordinarily used by users (such as the / tree). You wouldn't want looking up /dev/console or /servers/something to examine its passive translator setting and start new ones up--you want to connect to the existing active translators attached to those underlying nodes. So, in general, the translator mode bits should not be set on the underlying node and if they are, then that's probably telling you that you really do want to act on them as normal. (I am imagining a "notrans" translator that passes everything through except that it applies O_NOTRANS to all the lookups. Then you could layer fakeroot on notrans on a directory, to get a shadow world of translators started by the fakeroot owner that get the fakeroot'd nodes as their underlying nodes when fakeroot/netfs starts them up.)
The point of all that is to say that the root node is a special case for fakeroot. You shouldn't diddle the mode bits of all nodes generically. All other fakeroot "underlying nodes" ports are gotten from a lookup without O_NOTRANS, so they are already what you should be presenting. The root node is the actual underlying node that has the fakeroot translator set on it, so for that you want to simulate the behavior of the untranslated node. Which is to say, how about this patch instead? To make cases like the current state less confusing, perhaps netfs (and diskfs) should do something special for an EOPNOTSUPP return from *_get_translator in lookup/getroot. It will only come up there if S_IPTRANS is set, which the *_validate_stat hook should only set if *_get_translator is going to work right. So it's an internal bogosity for it then to return EOPNOTSUPP. It could translate that to EIO or EGRATUITOUS or something, or just use an assert. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd