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

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > Tom Lord wrote:

    > > But it is impossible to write usefully correct code that would print
    > > only:

    > >         "%s is not readable\n", path

    > > (The message printed may be correct but it may not be what the actual
    > > problem was.)

    > One way to address the problem would be to put a test for
    > readability before the stat.  That would be a pessimization, but
    > it would have the same behaviour as doing the test after the
    > stat if the stat failed.

    > Since unreadable directories are a showstopper, what's wrong with 
    > reporting that problem if it's encountered?

The "check oil" warning light on my car has started going on at random
intervals (actually, there's a pattern to it but it took a while to
figure out).  This is a critical warning light that's supposed to mean
"Stop Driving Now or Your Engine Will Seize Up and Your Car Will Soon
Suddenly Become an Inert and Permanently Useless Pile of Scrap Metal
That You Will Have to _Pay_ Somebody to Take Away!".

Meanwhile: (1) I absolutely must drive about 150 miles this weekend to
complete the move.  (2) There's no chance of getting the engine
serviced until monday.

Thankfully, I was able to get a mechanic to take a quick look at the
situation and listen to me describe the detailed symptoms.  He's about
89% confident that the warning light is signaling that..... guess what
....

The test device that controls the warning light is broken.

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.

Ok, in the case of the oil light .... it's actually The Right Thing.
After all, an oil pump failure or engine drained of oil are
car-ruining (even life-endangering) conditions.  An annoyance every 14
years because it goes off spuriously is a small price to pay ---
especially since this particular sensor went off once before, in the
past, quite correctly (and thus saved the day).

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?

And at what cost?  Eventually, your proposed test will fail
_incorrectly_ and tla will abort when it doesn't have to.  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.

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

-t


p.s.:

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

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.

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

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