Re: rm patch suggestion

[Niels Möller]

Roland McGrath <roland@frob.com> writes:

> You'll have to tell me specifically what Hurd details you are talking
> about, not refer to what someone else speculated earlier.  You seem to be
> confused, and I cannot help if you do not spell out what you think is going
> on.

Let me try.

The scenario is as this: I open a directory node with O_NOTRANS
(alternatively, I open a directory node without specifying any extra
flags, and it has a translator attached to it *after* I open it, but
before the below fchdir). The result of this operation is an fd. In
both cases, there now is a node in the filesystem with a translator
attched to it, and my fd refers to the underlying node.

Next, I fchdir using this fd. The expectation is that I will end up
with a CWDIR-port that is *not* translated. A translator may or may
not be running, but if it is, my CWDIR should still refer to the
underlying node, the very same node as the fd I gave to fchdir.

But that seems not to be how fchdir works. Markus quoted some code,
more precisely the functions
  
  int
  _hurd_change_directory_port_from_fd (struct hurd_port *portcell, int fd)

and

  int
  __fchdir (fd)
     int fd;

The _hurd_change_directory_port_from_fd looks up "." (using
__file_name_lookup_under and zero flags, in particular no O_NOTRANS)
in the open directory, and installs the *result of this lookup* as the
CWDIR of the process. The problem is that the node "." refers to has a
translator attached, and therefore the lookup of "." results in a
port to the translator, not to the underlying node.

So I end up with a CWDIR that is a port to the translated node, not
the underlying node. Which is contrary to the expectations on
O_NOTRANS.

Are we misreading the _hurd_change_directory_port_from_fd code? Is
lookup of "." magic, ignoring the translator setting of the node? Or
is fchdir(open(..., O_NOTRANS)) broken?

/Niels