[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] [HEY TOM!] unhelpful error for unreadable directories
Date: Sat, 24 Apr 2004 22:44:58 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040306)

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]