Date: Sat, 1 Apr 2017 12:09:36 -0500 From: Lewis Donzis <lew@perftech.com> To: Eitan Adler <lists@eitanadler.com> Cc: FreeBSD Standards <freebsd-standards@freebsd.org>, freebsd-bugs@freebsd.org Subject: Re: Fix cp not to give chflags error on NFS Message-ID: <B6FF4891-B29E-4958-BC55-B567936FA8F7@perftech.com> In-Reply-To: <CAF6rxgkG_SuuVH2HNc6Wd9v7XCQPfAxhfUZk1KQWB_pXyj-KeA@mail.gmail.com> References: <8FDBAA2C-93B8-49FA-B3CD-5B709A93A5C4@perftech.com> <CAF6rxgkG_SuuVH2HNc6Wd9v7XCQPfAxhfUZk1KQWB_pXyj-KeA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@eitanadler.com> wrote:
>
> +freebsd-standards for folks that know more than I do
>
> On 1 April 2017 at 08:54, Lewis Donzis <lew@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B6FF4891-B29E-4958-BC55-B567936FA8F7>