From owner-freebsd-standards@freebsd.org Sat Apr 1 17:12:51 2017 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90EEAD29D36 for ; Sat, 1 Apr 2017 17:12:51 +0000 (UTC) (envelope-from lew@perftech.com) Received: from smtp-gw.pt.net (smtp-gw.pt.net [206.210.194.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp-gw.pt.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D74DC53 for ; Sat, 1 Apr 2017 17:12:50 +0000 (UTC) (envelope-from lew@perftech.com) X-ASG-Debug-ID: 1491066679-09411a12f82198940001-5PiRTR Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by smtp-gw.pt.net with ESMTP id 6mHg5IcxgDejv4vF (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 01 Apr 2017 12:11:19 -0500 (CDT) X-Barracuda-Envelope-From: lew@perftech.com X-Barracuda-Effective-Source-IP: mail.pt.net[206.210.194.11] X-Barracuda-Apparent-Source-IP: 206.210.194.11 Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 2E76484260D; Sat, 1 Apr 2017 12:09:38 -0500 (CDT) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id AxeI34vTFoEr; Sat, 1 Apr 2017 12:09:37 -0500 (CDT) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id B89BC84260E; Sat, 1 Apr 2017 12:09:37 -0500 (CDT) X-Virus-Scanned: amavisd-new at pt.net Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id HRf5bPwK4bMQ; Sat, 1 Apr 2017 12:09:37 -0500 (CDT) Received: from lewhome-dhcp-179.pt.net (lewhome-dhcp-179.pt.net [206.210.207.179]) (Authenticated sender: lew@pt.net) by mail.pt.net (Postfix) with ESMTPSA id 77A8A84260D; Sat, 1 Apr 2017 12:09:37 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Fix cp not to give chflags error on NFS From: Lewis Donzis X-ASG-Orig-Subj: Re: Fix cp not to give chflags error on NFS In-Reply-To: Date: Sat, 1 Apr 2017 12:09:36 -0500 Cc: FreeBSD Standards , freebsd-bugs@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8FDBAA2C-93B8-49FA-B3CD-5B709A93A5C4@perftech.com> To: Eitan Adler X-Mailer: Apple Mail (2.3259) X-Barracuda-Connect: mail.pt.net[206.210.194.11] X-Barracuda-Start-Time: 1491066679 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://smtp-gw.pt.net:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 2018 X-Virus-Scanned: by bsmtpd at pt.net X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.37719 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 17:12:51 -0000 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 wrote: >=20 > +freebsd-standards for folks that know more than I do >=20 > On 1 April 2017 at 08:54, Lewis Donzis 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