Re: master fails to build on FreeBSD when ACL support is on

[Eli Zaretskii <eliz@gnu.org>]

> Cc: jrm@ftfl.ca, ashish@FreeBSD.org, monnier@IRO.UMontreal.CA,
>  emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 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.