From owner-freebsd-standards@freebsd.org Sun Mar 26 21:00:38 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 36380D1FC16 for ; Sun, 26 Mar 2017 21:00:38 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F0731F2B for ; Sun, 26 Mar 2017 21:00:38 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2QL013u069669 for ; Sun, 26 Mar 2017 21:00:37 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201703262100.v2QL013u069669@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-standards@FreeBSD.org Subject: Problem reports for freebsd-standards@FreeBSD.org that need special attention Date: Sun, 26 Mar 2017 21:00:37 +0000 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: Sun, 26 Mar 2017 21:00:38 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 193594 | stddef.h should define max_align_t Open | 191586 | FreeBSD doesn't validate negative edgecases in bi 2 problems total for which you should take action. From owner-freebsd-standards@freebsd.org Sat Apr 1 16:50:52 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 A1260D2910F for ; Sat, 1 Apr 2017 16:50:52 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 628338F2 for ; Sat, 1 Apr 2017 16:50:52 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x229.google.com with SMTP id f204so22057745ybc.2 for ; Sat, 01 Apr 2017 09:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hcf8Fda+J3GfXERmdhCpQCAtLPK4J5G5wNGtjK6jiTs=; b=dRec5klBz9h9apAnXg2MXWE5gmeNGKI+SmBfj/QO0LJ7+pvvlUgi7FY68b7XuN/35D mQYXBPFEa5kGMqOnhtNjhPT7e53SOqWZ8U0scEED5JNxEkVa6myhHYk1NPkci5Tf1+6m pBNkkPZX6Lljs6vfEkbbXlY62oGgYYdEc7Hjw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hcf8Fda+J3GfXERmdhCpQCAtLPK4J5G5wNGtjK6jiTs=; b=uUDu5/ojaCN6ZNlt07dpvCciShWjFZH7D3VF7JjtdtoBNCVYXMbwMAlAbym5EVkzgr 2m5RvwLIrNNBthdQSD6UkMdFt+SoZltVz4OYtiX+JoksQYmZ3M07WFsYuyfbcdNj4YvK 9a6LJOTgqasOcyg8bdMCYm/dcxRmJMHZU+1H8Beh32d3rq7qrSOcdeE3X3X4/cYTX62w R3i0D7Raw+RR99OFXLlnD/v2fNOYMd+fnVA2BS6c9+VAI13gh1l1fJSUXO3L53MbIsLz 3DSn4pktyCU/U4YS1Nf8R4Yr9v2v5ne+Srorbx9XMjzimUmRK5GvuyhzwfPPl29NAaQ0 dBGw== X-Gm-Message-State: AFeK/H1M32cb/Gz/sWdOEzN7b+hzK9h50vsRQL/Hc6lUNIikbktRPSvG/YQM33RPcdGFWx7xWEmURaegmVs7sw== X-Received: by 10.37.164.68 with SMTP id f62mr6108194ybi.78.1491065451219; Sat, 01 Apr 2017 09:50:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.246.4 with HTTP; Sat, 1 Apr 2017 09:50:20 -0700 (PDT) In-Reply-To: <8FDBAA2C-93B8-49FA-B3CD-5B709A93A5C4@perftech.com> References: <8FDBAA2C-93B8-49FA-B3CD-5B709A93A5C4@perftech.com> From: Eitan Adler Date: Sat, 1 Apr 2017 09:50:20 -0700 Message-ID: Subject: Re: Fix cp not to give chflags error on NFS To: Lewis Donzis , FreeBSD Standards Cc: freebsd-bugs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 16:50:52 -0000 +freebsd-standards for folks that know more than I do On 1 April 2017 at 08:54, Lewis Donzis wrote: > It's fairly annoying that cp has no way to suppress the chflags error whe= n 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 !=3D ENOTS= UP) { > > which simply ignores the error if the destination filesystem doesn't supp= ort chflags? I believe POSIX requires this error: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html =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 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 Eitan Adler 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 From owner-freebsd-standards@freebsd.org Sat Apr 1 18:16:53 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 9D3D3D290AA; Sat, 1 Apr 2017 18:16:53 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8EE206; Sat, 1 Apr 2017 18:16:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id A4234D4AC32; Sun, 2 Apr 2017 04:16:43 +1000 (AEST) Date: Sun, 2 Apr 2017 04:16:42 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Eitan Adler cc: Lewis Donzis , FreeBSD Standards , freebsd-bugs@freebsd.org Subject: Re: Fix cp not to give chflags error on NFS In-Reply-To: Message-ID: <20170402032137.J13168@besplex.bde.org> References: <8FDBAA2C-93B8-49FA-B3CD-5B709A93A5C4@perftech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=AYLBJzfG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=bwFfXAZbAAAA:8 a=uZvujYp8AAAA:8 a=0gzIzi41aAwVIKEXhQ8A:9 a=CjuIK1q_8ugA:10 a=2U6tby81L7cA:10 a=La9TTo0hhEuW2XSksXFn:22 a=SLzB8X_8jTLwj6mN0q5r:22 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 18:16:53 -0000 On Sat, 1 Apr 2017, Eitan Adler wrote: > +freebsd-standards for folks that know more than I do > > 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. >> >> 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? This would break cp. Some corresponding breakage is mv has been committed, but it is so broken that it has no effect in the usual case where there is a chflags() error. IIRC, the usual case is mv of a directory (tree) across file systems. That is done using cp -pR (although cp has bugs like snapping hard links than make it unsuitable for that), so the error is detected as above. IIRC, mv handles the case of moving single files across file systems, and breaks it in a more sophisticated way than just ignoring the error. > 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. > === File flags are an extension, so POSIX doesn't require anything for them. In the above it just allows the implementation to duplicate. This allowance is not quite vacuous, since it requires the diagnostic if for failure to duplicate the implementation-defined bits, and disallows duplication of bits unless the implementation defines (that is, documents) that it attempts to duplicate them. mv also has the special handling for setugid bits. This is for security. Some file flags are important for security too, so errors duplicating them are more important than most errors and should not be silently ignored. POSIX in 2001 also requires mv to duplicate file times. This is impossible in many cases, at least with file times that POSIX didn't support in 2001, since the source file time might have more precision than the target can represent. Some fuzziness must be allowed. I think later versions of POSIX specify some fuzziness. But an application like make might need exact duplication of nanoseconds. msdosfs silently ignores some errors but not others. It often gets this backwards. For file times, some of the file systems that it supports can only represent times to the nearest 2 seconds, so they cannot duplicate even POSIX-2001 seconds resolution. msdosfs silently rounds to 2-second boundaries and reports successful duplication. This is not very good error handling. cp and mv need to know if the file system will silently round, and if not they need to read back the time to see if it was duplicated. The check should be optional. Similarly for most attributes, but default to checking for almost everything, or everything including file times. I use an application 'cpattrs' for comparing and duplicating attributes. Its args specify which attributes to duplicate. File times can be rounded before duplication or compared fuzzily. > 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. Technically, not if you try to copy the bits, and it is too easy for the user to forget which file systems support file flags and whether the source has any important ones, unless at least 1 diagnostic is printed. Anyway, some flags are too important to ignore errors for. The bug in mv is to ignore fails mainly for copying the archive flag. This is a fairly unimportant flag. cpattrs allows specifiying which attributes to compare and copy, but it doesn't support specifying individual bits in flags. nfs should support file flags iff the server does. Unfortunately, there is no protocol to set them (at least in nfs3). Bruce From owner-freebsd-standards@freebsd.org Sat Apr 1 18:43:52 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 37D72D29728 for ; Sat, 1 Apr 2017 18:43:52 +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 F2911F8E for ; Sat, 1 Apr 2017 18:43:51 +0000 (UTC) (envelope-from lew@perftech.com) X-ASG-Debug-ID: 1491072109-09411a12f8219f8a0001-5PiRTR Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by smtp-gw.pt.net with ESMTP id 1lBxxEHNy0FsLaap (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 01 Apr 2017 13:41:49 -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 DB97B842602; Sat, 1 Apr 2017 13:41:49 -0500 (CDT) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id QFxiKQ25QyfS; Sat, 1 Apr 2017 13:41:49 -0500 (CDT) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 28909842610; Sat, 1 Apr 2017 13:41:49 -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 KpPo19HNxmVO; Sat, 1 Apr 2017 13:41:49 -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 BE9D0842602; Sat, 1 Apr 2017 13:41:48 -0500 (CDT) From: Lewis Donzis Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Fix cp not to give chflags error on NFS Date: Sat, 1 Apr 2017 13:41:47 -0500 X-ASG-Orig-Subj: Re: Fix cp not to give chflags error on NFS In-Reply-To: <20170402032137.J13168@besplex.bde.org> Cc: Eitan Adler , FreeBSD Standards , freebsd-bugs@freebsd.org To: Bruce Evans References: <8FDBAA2C-93B8-49FA-B3CD-5B709A93A5C4@perftech.com> <20170402032137.J13168@besplex.bde.org> X-Mailer: Apple Mail (2.3259) X-Barracuda-Connect: mail.pt.net[206.210.194.11] X-Barracuda-Start-Time: 1491072109 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: 7617 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=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.37721 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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 18:43:52 -0000 > On Apr 1, 2017, at 1:16 PM, Bruce Evans wrote: Thanks for the detailed explanation. As I mentioned later, the problem seems to be more lated to the NFSv4 = server running Linux (FWIW, the underlying filesystem on our Linux NFS = server is ZFS). > nfs should support file flags iff the server does. Unfortunately, = there > is no protocol to set them (at least in nfs3). We switched to NFSv4 in the hopes that it would solve this. And, in = fact, it does if the server is running FreeBSD. But on Linux, not only does the ACL (which we never set) appear to cp = not to be =E2=80=9Ctrivial=E2=80=9D, but it fails to set. I=E2=80=99ve = added some details below, if it=E2=80=99s of any interest. We were already in the process of switching our NFS servers from Linux = to FreeBSD anyway, so this will just accelerate the process. Thanks, lew Using a Linux NFSv4 server: root@fbdev:/shared/lew # mount ******:/shared on /shared (nfs, nfsv4acls) root@fbdev:/shared/lew # cp -p xx yy nfsv4 err=3D10032 cp: failed to set acl entries for yy: Operation not permitted root@fbdev:/shared/lew # ls -l xx yy -rwxrwxr-x+ 1 root wheel 4821 Apr 25 2009 xx -rwxrwxr-x+ 1 root wheel 4821 Apr 25 2009 yy root@fbdev:/shared/lew # getfacl -v xx # file: xx # owner: root # group: wheel = owner@:read_data/write_data/execute/append_data/read_attributes/write_attr= ibutes/read_acl/write_acl/synchronize::allow = group@:read_data/write_data/execute/append_data/read_attributes/read_acl/s= ynchronize::allow = everyone@:read_data/execute/read_attributes/read_acl/synchronize::allow Using a FreeBSD NFSv4 server: root@fbdev:/mnt/lew # mount ******:/shared on /mnt (nfs, nfsv4acls) root@fbdev:/mnt/lew # cp -p xx yy root@fbdev:/mnt/lew # ls -l xx yy -rwxrwxr-x 1 root wheel 4821 Apr 25 2009 xx -rwxrwxr-x 1 root wheel 4821 Apr 25 2009 yy root@fbdev:/mnt/lew # getfacl -v xx # file: xx # owner: root # group: wheel = owner@:read_data/write_data/execute/append_data/read_attributes/write_attr= ibutes/read_xattr/write_xattr/read_acl/write_acl/write_owner/synchronize::= allow = group@:read_data/write_data/execute/append_data/read_attributes/read_xattr= /read_acl/synchronize::allow = everyone@:read_data/execute/read_attributes/read_xattr/read_acl/synchroniz= e::allow From owner-freebsd-standards@freebsd.org Sat Apr 1 23:39:07 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 71A6CD29E25 for ; Sat, 1 Apr 2017 23:39:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 58342C84 for ; Sat, 1 Apr 2017 23:39:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v31Nd7aN068747 for ; Sat, 1 Apr 2017 23:39:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-standards@FreeBSD.org Subject: [Bug 218300] [LIBM] implementations of sincos, sincosf, and sincosl Date: Sat, 01 Apr 2017 23:39:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: sgk@troutmask.apl.washington.edu X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-standards@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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 23:39:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218300 Bug ID: 218300 Summary: [LIBM] implementations of sincos, sincosf, and sincosl Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: standards Assignee: freebsd-standards@FreeBSD.org Reporter: sgk@troutmask.apl.washington.edu Created attachment 181395 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D181395&action= =3Dedit patch The attached patch implements sincos, sincosf, and sincosl. The primary benefit of these functions is that argument=20 reduction is done once instead of twice in independent calls to sin() and cos(). * lib/msun/Makefile: . Add s_sincos[fl].c to the build. . Add sincos.3 documentation. . Add appropriate MLINKS. * lib/msun/Symbol.map: . Expose sincos[fl] symbols in dynamic libm.so. * lib/msun/man/sincos.3: . Documentation for sincos[fl]. * lib/msun/src/k_sincos.h: . Kernel for sincos() function. This merges the individual kernels for sin() and cos(). The merger offered an opportunity to re-arrange the individual kernels for better performance. * lib/msun/src/k_sincosf.h: . Kernel for sincosf() function. This merges the individual kernels for sinf() and cosf(). The merger offered an opportunity to re-arrange the individual kernels for better performance. * lib/msun/src/k_sincosl.h: . Kernel for sincosl() function. This merges the individual kernels for sinl() and cosl(). The merger offered an opportunity to re-arrange the individual kernels for better performance. * lib/msun/src/math.h: . Add prototytpes for sincos[fl](). * lib/msun/src/math_private.h: . Add RETURNV macros. This is needed to reset fpsetprec on I386 hardware for a function with type void. * lib/msun/src/s_sincos.c: . Implementation of sincos() where sin() and cos() were merged into one routine and possibly re-arranged for better performance. * lib/msun/src/s_sincosf.c: . Implementation of sincosf() where sinf() and cosf() were merged into one routine and possibly re-arranged for better performance. * lib/msun/src/s_sincosl.c: . Implementation of sincosl() where sinl() and cosl() were merged into one routine and possibly re-arranged for better performance. --=20 You are receiving this mail because: You are the assignee for the bug.=