Re: Improve reporting of I/O, access errors for Emacs

[Eli Zaretskii]

> Cc: address@hidden
> From: Paul Eggert <address@hidden>
> Date: Thu, 12 Sep 2019 11:27:28 -0700
> 
> On 9/12/19 11:04 AM, Eli Zaretskii wrote:
> > We should instead have such logic on higher levels, where the
> > semantics and the meaning of errors are clear.
> 
> If lower levels suppress the info, logic on higher levels cannot obtain 
> the information and therefore cannot deal with the errors. So there must 
> be some change to the lower levels, regardless of what changes might be 
> advisable at higher levels.

I wasn't questioning changes on lower levels, I was questioning
signaling errors there.

> > if Emacs just needs
> > to return some information about a file, and the file turns out to be
> > inaccessible, why do we need to signal an error
> 
> The same reason insert-file-contents signals an error when a file is 
> inaccessible: the requested information is not available, and this is an 
> exceptional condition.

The analogy is incorrect: insert-file-contents is the level where I
think we can signal errors, because that level knows what these errors
mean from the application point of view: the application wanted to
have a file in a buffer, but that couldn't be done.  Same with
copy-file, delete-file, etc.

But your changes signal errors from stuff like emacs_readlinkat,
file_name_case_insensitive_p, and file_directory_p.  On that level, we
have no idea whether an error is critical or not.  We should just set
errno and return an error indication, and then let the caller deal
with that.

> I should mention that I've been trying out the new code and it works 
> fine for me.

That's too small a sample, so it doesn't prove much in my book, sorry.