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

[Aaron Bentley]

Tom Lord wrote:

> We disagree (apparently) about adding new system calls to try to
> second guess for the OS why the lstat failed or might fail --
> specifically testing for searchability of `path'.  I say "don't do
> that" because if you do you'll be creating a new catastrophic failure
> mode -- the command will fail in some environments when it would not
> fail if the extra test were not present.  

I didn't express myself well there.  When I proposed testing beforehand, 
it was only for the purpose of showing that I felt it was okay to test 
afterward, since testing beforehand would be no different from testing 
afterward.  You said, "The message printed may be correct but it may not 
be what the actual problem was."  I felt that it would be okay to print 
the wrong error, given that there was an error, and the wrong error was 
a showstopper.  You've since convinced me that the wrong error may not 
be a showstopper.

> You also say "newbies will chuck it, otherwise" which
> I consider to be unsubstantiated FUD.

It's not a binary thing, but I think the more cryptic and alarming the 
error messages are, the more users will give up on Arch before they 
really understand it.

I think it's really wierd that when the problem is an unsearchable 
directory named foo, users will get an error message about a 
non-existant directory named foo/{arch}.  I think it's unfortunate that 
the error message is one that new users will encounter when they do 
"import".

> Your own anecdote contradicts your FUD.   The newbie didn't chuck it
> even with the old crappy error message.   The newbie asked for help on
> IRC.   You could try to say "most newbies won't do that" or "irc isn't
> always helpful" but at that point we're getting into pure speculation
> about what might or might not happen.    In essense, you're just
> making up a problem out of thin air and trying to make it sound
> important by asserting it has something to do with new adopters.

Okay, let's leave that be.

>     > Arch is powerful, and I want it to succeed.  But in spots, it
>     > has poor usability, and I think that could hold it back, so I'm
>     > trying to improve that.
>
> And nobody disagrees or is trying to stop or discourage you -- just to
> make sure that your proposed improvements are, in fact, improvements.

We place different priorities on helpfulness vs correctness, so we 
sometimes disagree about what's an improvement.

>     > No.  I was proposing testing for unsearchability only if I
>     > couldn't stat $foo/{arch}.
>
> No, you weren't.  You started off that way several messages back but
> when I pointed out problems with it you changed your proposal thusly:
>
>     > 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.

Yeah.  That was meant to prove that doing it afterwards was okay, since 
the only difference between doing it beforehand and doing it afterwards 
was that doing it afterwards was faster.

>     > "Permission denied attempting to check attributes of $foo/{arch}"
>
>     > will be misleading, but if that's the best we can do, it's
>     > better than what we currently have.  I suppose we could add "(is
>     > $foo searchable?)"  for the EACCES case...
>
>
> That message is ok.  I like the more literal one I gave above, as
> well.  I'm against the proposed parenthetical comment

How about this:

"Error encountered checking for nested project trees in %s:\n%s 
accessing %s\n", directory, errno_to_string (errn), file);

That way we get to name the directory without making any guesses, and 
there's some context to help explain the filename.

Aaron