[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 01:54:55 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040306)

Tom Lord wrote:
    > From: Aaron Bentley <address@hidden>

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

FUD is not an argument.

You were saying the error was a trivial thing. Maybe it's rare, but I've encountered it too. Maybe it's 10 minutes once you know what to expect, but it took longer than 10 minutes for me to sort out. And when it came up in IRC, the other guy who was helping went in an utterly wrong direction. (He thought it meant that the tree root was missing {arch})

Maybe I overstated it, but I was reacting to what I felt was an understatement.

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

Then write the error message carefully to avoid that confusion.

That's why I asked for your help.

    > b) they may conclude that tla is borked and chuck it

I stopped reading here.

That's disappointing, as I did spend some time and thought on it.

I came up with the following message, for the case where the stat errno is EACCES:
"Cannot access contents of directory $foo"

Unfortunately, this assumes that $foo is a directory, and I don't have a guarantee that it is. I think that:

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


reply via email to

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