Re: [Gnu-arch-users] [HEY TOM!] unhelpful error for unreadable directories

[Aaron Bentley]

Tom Lord wrote:
> There's few things more annoying than a failure detection system whose
> rate of failure is comperable to or greater than the system it's
> supposed to be protecting.

No, I was talking about a better error message when an error message was 
already inevitable.

> But this subdir stuff:  you're not talking about "saving the day".
> You're talking about saving somebody, what, say an average of 10m
> puzzling over a rare, confusing error message?

No, since this error will typically happen during or before their tla 
import, these will tend to be new users.  And they'll conclude that tla 
is borked and chuck it.

And if they get an error message that tla was unable to test for the 
existance of {arch} in subdirectory that isn't supposed to have one

a) they may conclude that tla requires an {arch} in every subdir
b) they may conclude that tla is borked and chuck it

> And at what cost?  Eventually, your proposed test will fail
> _incorrectly_ and tla will abort when it doesn't have to.  

No.  I was proposing testing for unsearchability only if I couldn't stat 
$foo/{arch}.

> Unlike a
> scary red light on my dashboard, an abort by tla is a problem that
> can't be solved short of modifying and recompiling tla.

Yes.  And this error message requires either an strace or recompiling 
tla to desciper.

> So, you're solving a rare confusing error message with a rarer yet
> _catastrophic_ failure mode.  No, that's not The Right Thing.

Not a new failure mode.  Just a better error message for those cases 
where the problem can be diagnosed.

> It would actually have to be a "searchability" test, not a
> "readability" test, since unreadable directories can still be
> searchable and that's all we actually need to detect a subtree.
>
> And it's not guaranteed to be correct.  Never underestimate the
> perversity of what people can do to filesystem semantics without
> violating the letter of Posix and/or (like NFS or AFS) what people
> will consider "reasonable".

For the case where errno is EACES, how could "Cannot access contents of 
directory $foo" be wrong?  Barring concurrent changes, we must have 
access to the parent directories to determine the name of the child 
directory.  And even if there have been concurrent changes, such that we 
can no longer access a parent directory, it's still true that we can't 
access the child directory's contents.

Also, there is a filesystem coming down the pike where the presence of 
$foo/{arch} will indicate that file $foo has an attribute {arch}.

> The only thing inventory _needs_ to be able to do to discover if a
> subdir is a subtree is successfully lstat for a possibly non-existent
> {arch} file.

Additionally, tla needs to access the directory contents if {arch} is 
not present.

> Operating systems have quite a bit of (even somewhat reasonable)
> liberty for how they provide for that and portable unix permission
> bits aren't really a constraint on the OS.
>
> Consider for example that the `x' permission on a directory that lacks
> `r' is pretty weak protection.  A finer-grained control might allow a
> user to search for _certain_ files but not all --- e.g., the dir might
> lack `x' yet you can still (as a special exception) see if it contains
> '{arch}'.

And you're saying that's okay?  A mostly unreadable directory is 
acceptable to tla?  What happens when we conclude that {arch} isn't 
present and try to list the contents of that directory so we can lint it?

> The test you propose here would just get in the way on such a system.

No, such a system would just get in the way of tla.

Unless people are testing tla on such a system, it's reasonable to 
conclude that it probably doesn't work on such a system anyway.  It 
probably doesn't work on Reiser 4 either.

Aaron