From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Improve reporting of I/O, access errors for Emacs Date: Thu, 12 Sep 2019 22:34:58 +0300 Message-ID: <83a7b91f6l.fsf@gnu.org> References: <83d0g51jdp.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="163168"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 12 21:35:32 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i8UsK-000gEY-Ei for ged-emacs-devel@m.gmane.org; Thu, 12 Sep 2019 21:35:28 +0200 Original-Received: from localhost ([::1]:37962 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i8UsJ-0008DV-Ci for ged-emacs-devel@m.gmane.org; Thu, 12 Sep 2019 15:35:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40875) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i8Urd-0008DP-Cv for Emacs-devel@gnu.org; Thu, 12 Sep 2019 15:34:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39991) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i8Urc-0003Qi-Qh; Thu, 12 Sep 2019 15:34:44 -0400 Original-Received: from [176.228.60.248] (port=2631 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i8Urc-00007Z-74; Thu, 12 Sep 2019 15:34:44 -0400 In-reply-to: (message from Paul Eggert on Thu, 12 Sep 2019 11:27:28 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:240001 Archived-At: > Cc: Emacs-devel@gnu.org > From: Paul Eggert > 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.