It's not clear to me what case gets EISDIR and what case hangs. I don't think any special case for "." or anything like that ought to be required. I am as confused as you are. For the EISDIR failure, find where that error is coming from. For the hang, figure out what port it is really talking to when it hangs.
It should be talking to the underlying filesystem, which should have no reason to hang. Hmm, except on the directory where you set the translator, where a lookup of "." might be trying to go back to the translator itself. I didn't make it use O_NOTRANS lookups, because that is not the behavior you want for handling mount points and /dev and so forth. But for a name that might in the underlying filesystem refer back to the root of the translated filesystem, there is a problem. There are some workaround we could try, but this won't come up with the unattached-root mode of operation. Probably the right thing to do is unlock the directory node while doing the lookups. That seems wise generally speaking--there must be other potential deadlock conditions too. I put in that change, which looks to me like it can't do any harm. However, if you are hitting the case of looking up the root of the filesystem then this will avoid the deadlock but not the whole problem. It might be the right thing for it to check for fsidport==netfs_fsys_identity after io_identity and short-circuit to returning the existing node. That seems a bit more dicey. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
