Re: Side-by-side configuration is incorrect reported as permission denied

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Aug 13 08:49, Andrew DeFaria wrote:
> On 08/13/2012 08:22 AM, Christopher Faylor wrote:
> >But you aren't really even suggesting that.  You are apparently just
> >suggesting that every windows error should be displayed by the Cygwin
> >DLL.  Wow.
> I never said "every" - you did.
> >>I would draw the border at "if there's an error message".
> >You clearly haven't thought this through.  Your screen would be filled with
> >errors.  What happens when something like bash looks for ~/.bashrc and it
> >doesn't exist?  You'd see a "File not found" on your screen.
> That's not even a valid example. Even bash doesn't report that as an
> error as it isn't an error. You're being way to literal here. Let's
> change the statement "If there's an error, that you are gonna
> report, then you should report the best error that you can. One that
> leads to a solution the quickest". Call me silly but saying
> "Permission denied" in this circumstance is not "the best error you
> can report".
> 
> >Ok, so you don't want that one.  You just want the error messages that you
> >care about.  Which of the thousands of Windows errors would we decide to
> >display and which would we ignore?  It's not a solvable problem.
> See above.
> >
> >>>As cgf pointed out, Windows has zillions of error codes.  We wouldn't
> >>>want to generate the same number of POSIX-like error codes.  It wouldn't
> >>>make a lot of sense since POSIX applications only test for a limited,
> >>>expected number of error codes, and it might break things.
> >>I was talking error *messages* not error *codes*.
> >Cygwin and other windows programs do not see error *messages* when
> >something fails, they see error *codes*.  Getting the error *message*
> >involves translating the error *code* into a *message*.  We aren't actively
> >stopping you from seeing an error message.  We are translating a windows
> >error code into a POSIX errno.  Then bash reports the error using a table
> >of error strings that it gets from Cygwin.
> It's the "translation" that seems to be the problem. I understand,
> there's no error code that better translates. This, to me, just
> points out the flaw in the design of error handling and it results
> in bad error messages like the infamous "not a typewriter".
> >The fact that this has to be explained to you pretty clearly illustrates that
> >you don't understand what is going on here.
> I do understand it. I gave a suggesting for how to better handle the
> error given the restrictions in the plumbing you describe.
> >You really should either go thoroughly educate yourself about this or just stop talking.  Earnie's
> >points made here: http://cygwin.com/ml/cygwin/2012-08/msg00257.html are
> >quite pertinent.
> Obviously you're not interested. So be it..

You can't be bothered to leave the high horse, right?  Did we really
sound like people *not* trying to solve this problem?  Unfortunately
not every solution is the best one, it always depends on the perspective
from where you're looking at it.  But you apparently don't want to see
that.  So, ok, probably you're right, we're obviously not interested.
So be it.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple