bug-hurd
[Top][All Lists]
Advanced

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

Re: rm patch suggestion


From: Roland McGrath
Subject: Re: rm patch suggestion
Date: Wed, 8 May 2002 18:19:01 -0400 (EDT)

Sorry, I am the one who was confused.  Niels's explanation is quite clear,
and exactly what I surmised reading over the code between making my last
posting and reading his reply.

> Are we misreading the _hurd_change_directory_port_from_fd code? 

No, you are right.  That is not what I intended it to do, but I don't think
I ever thought fully about the question before.

> Is lookup of "." magic, ignoring the translator setting of the node? 

No, it's not.  But I am beginning to think that it should be.

> Or is fchdir(open(..., O_NOTRANS)) broken?

Indeed it is.  It should be a simple and otherwise harmless fix to use
O_NOTRANS in hurdfchdir.c.  I will check that in.  I also added this comment:

                         /* We look up "." to force ENOTDIR if it's not a
                            directory and EACCES if we don't have search
                            permission.  */

(A similar comment in hurdchdir.c already explains the reason for the "."
lookup, which there is done without a second RPC by just appending "/." to
the name.  Note that in that case, this O_NOTRANS question is moot since
you are doing a normal name lookup that uses the translator anyway.)


There is no reason not to put that libc change in, so I have.  
However, it never occurred to me that it might be necessary.
It seems counter-intuitive and dangerous that it is.

So now fchdir will work.  But then you do "cd ." or examine any "./foo"
instead of "foo" and blamo! you get the translator you were trying to avoid.

The current treatment of "." is consistent with how any random link to any
node is treated, it just happens to have the name "." and be a hard link to
a directory.  It's also consistent with how ".." behaves in random
directories.  But it's inconsistent with how ".." behaves at the root of a
filesystem.  At the root of a filesystem, ".." gets you the original ".."
node passed into fsys_getroot, so no translator setting affects you.  At
the root of the root filesystem, ".." loops back to the root itself and
does not refer to any translator set on the / directory.

It seems to me that "." and ".." should be special cases in diskfs
that act as if O_NOTRANS had been used.




reply via email to

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