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=E2=80=99s running FreeBSD, then =
not only does the error not occur, cp doesn=E2=80=99t even attempt to =
set the ACL because it passes the acl_is_trivial_np() test.
So I=E2=80=99m 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:
>=20
> +freebsd-standards for folks that know more than I do
>=20
> 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.
>>=20
>> What do you think about the following change to =
/usr/src/bin/cp/utils.c:
>>=20
>> 398c398
>> < if (fdval ?
>> ---
>>> if ((fdval ?
>> 401c401
>> < chflags(to.p_path, fs->st_flags))) {
>> ---
>>> chflags(to.p_path, fs->st_flags))) && errno !=3D =
ENOTSUP) {
>>=20
>> which simply ignores the error if the destination filesystem doesn't =
support chflags?
>=20
> I believe POSIX requires this error:
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html
>=20
> =3D=3D=3D
> 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.
> =3D=3D=3D
>=20
> 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.
>=20
>=20
> --=20
> Eitan Adler
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B6FF4891-B29E-4958-BC55-B567936FA8F7>