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

[Paul Eggert <eggert@cs.ucla.edu>]

On 01/22/2018 12:32 PM, Eli Zaretskii wrote:
>> 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.

Sure, but this topic came up for a noninteractive invocation: the place 
where rename-file calls copy-file. If rename-file had a way of telling 
copy-file "Hey! use your best effort to copy permissions but don't 
signal an error if you can't", then rename-file could suppress the 
signal for failure to copy ACLs without suppressing the signal for other 
failures. (This may not be a good idea, though; please see below.)

> ACLs are not universally supported, and giving up on copying them doesn't
> mean the file is not protected.
I'm afraid that it does mean that, at least for GNU/Linux ACLs, as they 
can prevent you from accessing a file that you could otherwise access. 
In other words, if you copy a file but not its ACLs, a user may be able 
to access the copy even though they cannot access the original. This is 
an argument against silently continuing when ACLs cannot be copied.