[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: Sun, 25 Apr 2004 21:11:05 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4

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.


reply via email to

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