Fix cp not to give chflags error on NFS

Lewis Donzis lew at perftech.com
Sat Apr 1 17:12:51 UTC 2017


Hmmm, good point.

And I have to apologize.  After a bit more research, the real annoyance was not actually chflags, but attempting to set ACLs, specifically NFSv4 ACLs.

And to add to my embarrassment, this appears to be a problem only when the NFS server is running Linux.  If it’s running FreeBSD, then not only does the error not occur, cp doesn’t even attempt to set the ACL because it passes the acl_is_trivial_np() test.

So I’m sorry to have brought it up, I think all is well within the FreeBSD world.

Thanks,
lew



> On Apr 1, 2017, at 11:50 AM, Eitan Adler <lists at eitanadler.com> wrote:
> 
> +freebsd-standards for folks that know more than I do
> 
> On 1 April 2017 at 08:54, Lewis Donzis <lew at perftech.com> wrote:
>> It's fairly annoying that cp has no way to suppress the chflags error when the destination file is on an NFS mount.  A bigger problem than the error message is that it returns exit status 1, which causes things like make to fail when there really was no error.
>> 
>> What do you think about the following change to /usr/src/bin/cp/utils.c:
>> 
>> 398c398
>> <               if (fdval ?
>> ---
>>>              if ((fdval ?
>> 401c401
>> <                   chflags(to.p_path, fs->st_flags))) {
>> ---
>>>                  chflags(to.p_path, fs->st_flags))) && errno != ENOTSUP) {
>> 
>> which simply ignores the error if the destination filesystem doesn't support chflags?
> 
> I believe POSIX requires this error:
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html
> 
> ===
> The file permission bits and the S_ISUID and S_ISGID bits. Other,
> implementation-defined, bits may be duplicated as well. If this
> duplication fails for any reason, cp shall write a diagnostic message
> to standard error.
> ===
> 
> We can possibly define "implementation defined bits" to not include
> other flags if the flags are unsupported on the destination filesystem
> but this seems weird to me.
> 
> 
> -- 
> Eitan Adler



More information about the freebsd-bugs mailing list