On Fri, Sep 23, 2011 at 8:41 AM, Ian Kent <raven@xxxxxxxxxx> wrote:
>
> My point is that, since we haven't had any non-trivial problems reported
> due to the semantic change, in what six months or more, why change it
> now?
We may indeed have to revert for sanity at this point, but I have to
say that I think the arguments have been very weak, and the logic for
when to auto-mount and when not to seems to not really be based on any
real logic.
For example, I think the whole "let's consider lstat different from
stat" model is broken. It works for symlinks, but that's because
- applications *know* about the symlink difference
- lstat actually *informs* about the symlink
neither of which is true for automounts. So quite frankly, I think
trying to conflate automount behavior with symlink behavior is a
completely bogus model to begin with, and has no actual redeeming
values except for an implementation issue (->follow_link) that no
longer even exists!
So I seriously think that the old autofs model is technically
superior. Which doesn't make it the only right one, of course. But I
really do think it's totally broken to think that lstat works
differently from stat.
So I would argue that using lstat as a differentiator for this is bad, because
- it's not what we've done historically
- it's a crazy hack introduced by implementation reasons, not logic
- it's against all lstat documentation
- it's inflexible and makes it hard to script
Now, introducing a new internal kernel flag is in many ways even
*worse*, because it's going to make it even more ad-hoc and
implementation issue, and even less visible and logical to actual
users who don't care.
So *that* is why I thought the LOOKUP_DIRECTORY flag was so nice. And
I still suspect that if paired with LOOKUP_OPEN, it would actually be
a complete solution that avoids the crazy issues with "random
implementation detail" and could give us something that is both
accessible from user space *and* something we can explain to a user
from a logical basis.
In other words, if we are going to accept changing semantics (and
apparently we have to), let's just make sure the ones we pick are the
*sensible* ones.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
