From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas =?UTF-8?Q?Gr=C3=BCnbacher?= Newsgroups: gmane.emacs.bugs Subject: bug#20681: Build failure [MSYS2/MINGW64, OSX] Date: Sun, 31 May 2015 21:18:37 +0200 Message-ID: References: <55671056.9030604@alice.it> <83oal4wq59.fsf@gnu.org> <55685B1B.1040507@alice.it> <55689A39.7080804@cs.ucla.edu> <5568C1C8.2090406@cs.ucla.edu> <83siaeuzzk.fsf@gnu.org> <83lhg6uuyy.fsf@gnu.org> <83oal0u8g0.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1433099960 27419 80.91.229.3 (31 May 2015 19:19:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 May 2015 19:19:20 +0000 (UTC) Cc: 20681@debbugs.gnu.org, Paul Eggert , Nick Andryshak , Angelo Graziosi To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 31 21:19:11 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yz8lL-0007Sw-3x for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 May 2015 21:19:11 +0200 Original-Received: from localhost ([::1]:43229 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yz8lK-00062q-E5 for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 May 2015 15:19:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41704) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yz8lG-00062k-UR for bug-gnu-emacs@gnu.org; Sun, 31 May 2015 15:19:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yz8lC-0004Y0-Io for bug-gnu-emacs@gnu.org; Sun, 31 May 2015 15:19:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53367) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yz8lC-0004Xv-GC for bug-gnu-emacs@gnu.org; Sun, 31 May 2015 15:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yz8lC-0005eO-02 for bug-gnu-emacs@gnu.org; Sun, 31 May 2015 15:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andreas =?UTF-8?Q?Gr=C3=BCnbacher?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 May 2015 19:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20681 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20681-submit@debbugs.gnu.org id=B20681.143309992621700 (code B ref 20681); Sun, 31 May 2015 19:19:01 +0000 Original-Received: (at 20681) by debbugs.gnu.org; 31 May 2015 19:18:46 +0000 Original-Received: from localhost ([127.0.0.1]:35109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yz8kv-0005du-J5 for submit@debbugs.gnu.org; Sun, 31 May 2015 15:18:46 -0400 Original-Received: from mail-oi0-f43.google.com ([209.85.218.43]:35178) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yz8kt-0005de-1Q for 20681@debbugs.gnu.org; Sun, 31 May 2015 15:18:44 -0400 Original-Received: by oihd6 with SMTP id d6so88093523oih.2 for <20681@debbugs.gnu.org>; Sun, 31 May 2015 12:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zG9I9WqTTyOzg4sST5uFumNtKkwxq3/r1NUydxDNaFY=; b=IAha9llNkhkgezSdjWlMxPoHnBPXall9ishlq8dFJEjLt9+pOq/1B1lMVjXcqv4LZA ZnKGXmNH3On37noqToKyqZmlCiBC6hsfl0XmVQZBr8tcFa45Wgs46TKBL4JAX0bIHD2Z 1xG+DrQmYEAyTm0ikDbl+FUgOabYbdv7hdRIQDeyIM67ZXaMkf6w+kGjQlKglj0gg5Vw Al4S579Q/G6hbau8wvKn2amQyAiRV8sVp6CA4SBZ/XTBDk886RsKXaqps0JOLdn3wI0Y 98xq57jLZmqundk2NhvCHokPkwCmgiOF2nx53LlhwAHhGHIg66ngYAuZeKj+mIKNC6wE 5amA== X-Received: by 10.202.84.143 with SMTP id i137mr14334549oib.114.1433099917369; Sun, 31 May 2015 12:18:37 -0700 (PDT) Original-Received: by 10.182.143.72 with HTTP; Sun, 31 May 2015 12:18:37 -0700 (PDT) In-Reply-To: <83oal0u8g0.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:103408 Archived-At: Eli, 2015-05-31 16:29 GMT+02:00 Eli Zaretskii : >> Date: Sat, 30 May 2015 15:06:16 +0200 >> From: Andreas Gr=C3=BCnbacher >> Cc: Nick Andryshak , 20681@debbugs.gnu.org, >> Paul Eggert , Angelo Graziosi >> >> > Please tell what do you want to see in confg.h, specifically. I can >> > force the Emacs development head to compile set-permissions.c, so >> > perhaps Emacs's config.h will do. >> >> It may. I have no idea what kind of acl functionality emacs on MinGW >> should have though. > > Emacs built with MinGW has the same functionality on Windows as Emacs > does on Posix hosts: get a file's ACL as a text string, set a file's > ACL from text string description, and copy ACL from one file to > another. > > The relevant functions, acl_get_file, acl_set_file, acl_to_text, > acl_from_text, and acl_free are implemented as part of Emacs. So those are the functions that gnulib is seeing? If so, then emacs could provide acl_delete_def_file as well, and everything will be fine again. But shouldn't Windows ACL support be added to get_permissions() and set_permissions() proper instead of emulating Windows ACL support through the POSIX draft ACL interface? The _to_text() and _from_text() functions could be modified to take a struct permission_context argument; they could be moved into gnulib or remain part of emacs. As a side effect of that, cp in coreutils would then also do the right thin= g on Windows (if someone made coreutils build there again). >> What did it do before? > > The only ACL-related function that Emacs on Windows was using from > Gnulib was acl_errno_valid. All the rest were implemented in the > Emacs sources. > > IOW, the Gnulib ACL functions were almost completely unused in the > MinGW build. However, they did compile, which allowed us to keep the > Gnulib configuration very similar to what was used on Posix hosts. > Which is why I'm not sure it is worth your while to do more than > you've already done, unless you do want to make sure the code at least > compiles as it did before. > > With that caveat, I answer below your questions, regardless. > >> Is the build failure new or did it already exist before the acl >> rewrite? > > It is new. Before the rewrite, the file qcopy-acl.c would compile > with MinGW, although the function qcopy_acl was not called in the > MinGW build, and so qcopy-acl.o was not linked into the binary. But > it would at least compile. > > After the rewrite, qcopy-acl.c is just a thin wrapper around > get-permissions.c and set-permissions.c. The former still compiles > with MinGW, but the latter doesn't. The reason is this cpp > conditional: > > # ifndef HAVE_ACL_DELETE_DEF_FILE > # error Must have acl_delete_def_file (see POSIX 1003.1e draft 17). > # endif > > I don't understand why the code requires acl_delete_def_file where it > previously did not: it's not like setting permissions will absolutely > not work if there is no such function. I see now what has changed: qcopy_acl didn't call acl_delete_def_file before but it should have for directories. (The sibling function qset_acl did call acl_delete_def_file even before the rewrite.) > E.g., why not do something like the following instead: > > # ifndef HAVE_ACL_DELETE_DEF_FILE > ret =3D -1; > errno =3D ENOSYS; > # else > ret =3D acl_delete_def_file (name); > > # endif Nope, the call is really needed. > More generally, copying ACLs from one file to another does not need > any analysis of what's in the ACLs being copied: it could simply treat > the ACLs as an opaque object, something whose structure and semantics > are known only to the innards of acl_get_file and acl_set_file. So > building qcopy_acl on top of get_permissions and set_permissions, > which are more flexible, and do require that knowledge, is IMO > fundamentally wrong, as it makes much harder to port this simple and > important Gnulib function to other platforms. I disagree. Have a look at struct permission_context; acl_get_file() and acl_set_file() is part of the POSIX draft ACL API but other platforms have totally different data structures and interfaces. Windows ACLs should be implemented as another kind of ACLs, not disguised as POSIX ACLs. > After all, copying ACLs from one file to another is much more frequent > and important an operation than setting ACLs from user-specified > arguments. Probably, yes. > What's more, the assumption that if acl_get_file and acl_set_file are > available, then so should be acl_delete_def_file is yet another > obstacle, IMO gratuitous one. No, acl_get_file, acl_set_file, and acl_delete_def_file are all part of the POSIX ACL API, and acl_delete_def_file is needed for directories. >> Which acl related symbols do you have in config.h? > > HAVE_ACL_FREE > HAVE_ACL_FROM_TEXT > HAVE_ACL_GET_FILE > HAVE_ACL_SET_FILE > HAVE_SYS_ACL_H > USE_ACL > >> If it has acl_get_file and acl_set_file, where can I find >> documentation about what those functions do on MinGW? > > They do what you'd expect, but support only ACL_TYPE_ACCESS. They > know about ACL_TYPE_DEFAULT, but always return EINVAL for it, since > it's next to impossible (and not recommended) to have a directory on > Windows which has no default ACLs associated with it. > > You can see their sources in src/w32.c in the Emacs repository. That's just wrong. Windows ACLs can contain effective as well as inheritabl= e permissions; the split between types as with POSIX ACLs doesn't exist. Thanks, Andreas