Re: rm patch suggestion

[Niels Möller]

Roland McGrath <roland@frob.com> writes:

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

I'd expect that this issue matters primarily for programs that are
paranoid and traverses directory trees (I think rm -rf should by
default be in this class, but that's an independent design question),
and such programs should probably use O_NOTRANS for all accesses, not
just when opening directories.

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

It makes some sense to require that looking up "." should always be a
NOP, in the sense that "./foo" should always be equivalent to "foo"
and "foo/./bar" equivalent to "foo/bar". The ".." case is not as
clear to me, though, probably because I don't really know how uplinks
across translator boundaries work.

If that special treatment of the "." is implemented, another question
is if the special case is done on the client or the server side of the
dir_lookup call. Say my CWDIR refers to a port handled by some
filesystem server/translator. I look up ".". Should the glibc code
linked into my own process enforce that looking up "." returns my
CWDIR, or should the filesystem that handles my CWDIR have the freedom
to return something different if it so wishes? To me, it makes sense
to do it in glibc (i.e. on the client side), rather than in diskfs
(server side). It's a question of paranoia versus flexibility, I
guess.

Regards,
/Niels