[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rm patch suggestion
From: |
Thomas Bushnell, BSG |
Subject: |
Re: rm patch suggestion |
Date: |
08 May 2002 23:09:38 -0700 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
nisse@lysator.liu.se (Niels Möller) writes:
> I think you're asking how to get the other way, and you're suggesting
> that plain lookup of "." should do that. I feel that the True Meaning
> of the "." link should be to point back to itself, and not point along
> the "translated-as" dimension.
I disagree.
As it sits now, the that lookup (".", O_NOTRANS) gives you the node
itself, and lookup (".", 0) starts the translator and gives you its
root.
If you change it so that lookup (".", 0) doesn't start the translator,
then what do you do if you do want the translator? There would be no
way.
You suggest "O_TRANS", but there is no such flag, and in fact, that's
the default for all other lookups, right? So it should be the default
for all names.
> I think it's reasonable to expect that "foo/.." == "./foo/.." == "."
> if only the lookup of the "foo"-component is performed with O_NOTRANS.
"foo/.." should be the same as ".", even if foo is a translated node.
To make this work, ".." has to cross back up the translator boundary,
which is easy because the foo translator got a "dotdot" argument at
startup. If you do ".." from the root, you get that original
"dotdot". (This is the EAGAIN case of diskfs_lookup.) So look at
libdiskfs/dir-lookup.c; that case (if you are not in a shadow root)
pops you up to an FS_RETRY_REAUTH on the dotdot point. We should at
that point do a "." lookup on that node, and we do not at present.
This is perhaps a bug.
"./foo/.." should involve a lookup of "." which is not present in
"foo/..", if the current directory is a translated node (which we got
into by NOTRANS) then this will be different (and *should* be).
- Re: rm patch suggestion, (continued)
- Re: rm patch suggestion, Roland McGrath, 2002/05/08
- Re: rm patch suggestion, Oystein Viggen, 2002/05/08
- Re: rm patch suggestion, Niels Möller, 2002/05/08
- Re: rm patch suggestion, Roland McGrath, 2002/05/08
- Re: rm patch suggestion, Thomas Bushnell, BSG, 2002/05/08
- Re: rm patch suggestion, Roland McGrath, 2002/05/08
- Re: rm patch suggestion, Thomas Bushnell, BSG, 2002/05/08
- Re: rm patch suggestion, Roland McGrath, 2002/05/08
- Re: rm patch suggestion, Thomas Bushnell, BSG, 2002/05/08
- Re: rm patch suggestion, Niels Möller, 2002/05/08
- Re: rm patch suggestion,
Thomas Bushnell, BSG <=
- Re: rm patch suggestion, Niels Möller, 2002/05/09
- Re: rm patch suggestion, Marcus Brinkmann, 2002/05/09
- Re: rm patch suggestion, Niels Möller, 2002/05/09
- Re: rm patch suggestion, Thomas Bushnell, BSG, 2002/05/09
- Re: rm patch suggestion, Marcus Brinkmann, 2002/05/10
- Re: rm patch suggestion, Thomas Bushnell, BSG, 2002/05/10
- Re: rm patch suggestion, Niels Möller, 2002/05/08
- Re: rm patch suggestion, Marcus Brinkmann, 2002/05/08