From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master fails to build on FreeBSD when ACL support is on Date: Mon, 22 Jan 2018 22:32:40 +0200 Message-ID: <83y3kpzlav.fsf@gnu.org> References: <86o9lua0yx.fsf@phe.ftfl.ca> <834lnly8ht.fsf@gnu.org> <86vafy20sj.fsf@phe.ftfl.ca> <83o9lpuct5.fsf@gnu.org> <83lggtu1qn.fsf@gnu.org> <9dd64b10-78ce-c561-8c51-9e15b11e102c@cs.ucla.edu> <83bmhpt12i.fsf@gnu.org> <867escw93p.fsf@phe.ftfl.ca> <86vafwumqp.fsf@phe.ftfl.ca> <025ce2fd-a69a-12da-ce5b-c894d5636789@cs.ucla.edu> <83372zryx3.fsf@gnu.org> <4928e09c-e747-8754-973f-7b358ca3f5e7@cs.ucla.edu> <83inbtriv1.fsf@gnu.org> <83zi55zt7m.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1516653088 10453 195.159.176.226 (22 Jan 2018 20:31:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 22 Jan 2018 20:31:28 +0000 (UTC) Cc: jrm@ftfl.ca, ashish@FreeBSD.org, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 22 21:31:24 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1edikD-0001RR-Mn for ged-emacs-devel@m.gmane.org; Mon, 22 Jan 2018 21:31:05 +0100 Original-Received: from localhost ([::1]:36215 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1edimE-0004sq-0E for ged-emacs-devel@m.gmane.org; Mon, 22 Jan 2018 15:33:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1edim0-0004q7-V7 for emacs-devel@gnu.org; Mon, 22 Jan 2018 15:32:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1edilw-0005Sc-Tw for emacs-devel@gnu.org; Mon, 22 Jan 2018 15:32:56 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1edilw-0005SR-QQ; Mon, 22 Jan 2018 15:32:52 -0500 Original-Received: from [176.228.60.248] (port=3724 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1edilw-000496-8N; Mon, 22 Jan 2018 15:32:52 -0500 In-reply-to: (message from Paul Eggert on Mon, 22 Jan 2018 10:50:59 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:222155 Archived-At: > Cc: jrm@ftfl.ca, ashish@FreeBSD.org, monnier@IRO.UMontreal.CA, > emacs-devel@gnu.org > From: Paul Eggert > Date: Mon, 22 Jan 2018 10:50:59 -0800 > > On 01/22/2018 09:41 AM, Eli Zaretskii wrote: > > Why do we need to inform the callers that ACL setting failed > > Because they invoked copy-file with a non-nil preserve-permissions flag, > and copy-file cannot preserve the permissions as requested. It's the > same reason copy-file signals an error when invoked with a non-nil > keep-time flag and when it cannot keep the time on the output file. If > copy-file did not report an error, users would be lulled into thinking > that the destination has the same permissions as the source when > copy-file succeeds, even though that's not the case. Failure to keep time means a real problem that shouldn't just happen because of some feature of the filesystem that isn't supported. Any reasonable filesystem supports time-stamping files. By contrast, ACLs are not universally supported, and giving up on copying them doesn't mean the file is not protected. In fact, the user didn't even ask us to preserve ACLs, we just do it because it's a useful thing when it works. When it doesn't, it isn't a catastrophe, because the "normal" protection is still there. Anyway, I see that we disagree, so I will just stop trying. > One way to move forward would be to change copy-file to have a three-way > result, as set-file-acl does. That is, it could return t if successful, > nil if mildly unsuccessful, and signal an error if severely > unsuccessful. The distinction between return values is not relevant to interactive invocation.