From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#20681: Build failure [MSYS2/MINGW64, OSX] Date: Mon, 01 Jun 2015 20:39:35 +0300 Message-ID: <83vbf7s4yw.fsf@gnu.org> 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> <834mmrtqos.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1433180433 16785 80.91.229.3 (1 Jun 2015 17:40:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jun 2015 17:40:33 +0000 (UTC) Cc: 20681@debbugs.gnu.org, eggert@cs.ucla.edu, nandryshak@gmail.com, angelo.graziosi@alice.it To: Andreas =?UTF-8?Q?Gr=C3=BCnbacher?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 01 19:40:20 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 1YzThC-0000zu-7U for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Jun 2015 19:40:18 +0200 Original-Received: from localhost ([::1]:53647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzThB-0003Eg-95 for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Jun 2015 13:40:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzTh6-0003Bj-Pc for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2015 13:40:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzTh0-0006sm-1A for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2015 13:40:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54625) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzTgz-0006ra-Uj for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2015 13:40:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YzTgy-0005QP-EZ for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2015 13:40:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Jun 2015 17:40:04 +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.143318040020839 (code B ref 20681); Mon, 01 Jun 2015 17:40:04 +0000 Original-Received: (at 20681) by debbugs.gnu.org; 1 Jun 2015 17:40:00 +0000 Original-Received: from localhost ([127.0.0.1]:36367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YzTgt-0005Q1-B5 for submit@debbugs.gnu.org; Mon, 01 Jun 2015 13:39:59 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:50601) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YzTgp-0005Pl-Pm for 20681@debbugs.gnu.org; Mon, 01 Jun 2015 13:39:57 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NPA00H000FB0600@mtaout25.012.net.il> for 20681@debbugs.gnu.org; Mon, 01 Jun 2015 20:35:40 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NPA00FUW0VG0O40@mtaout25.012.net.il>; Mon, 01 Jun 2015 20:35:40 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il 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:103447 Archived-At: > Date: Mon, 1 Jun 2015 18:18:43 +0200 > From: Andreas Grünbacher > Cc: Nick Andryshak , 20681@debbugs.gnu.org, > Paul Eggert , Angelo Graziosi > > 2015-06-01 17:05 GMT+02:00 Eli Zaretskii : > >> 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. > > > > What would be the benefit of doing that, though? You will see in the > > Emacs sources that currently acl_to_text produces the Windows-specific > > SDDL string representation of the file's DACL security descriptor; > > making that Posix-compliant in order for those functions to be able to > > work with the likes of acl_from_mode is an extremely non-trivial and > > thankless job. > > You would add a Windows ACL to struct permission_context, add support for > it to get_permissions and set_permissions, and add > permission_context_from_text() and permission_context_to_text() functions. > > The _from_text and _to_text functions could initially only support POSIX and > Windows ACLs, which would be what emacs supports today; support > for other kinds of ACLs could be added later at any point. > > As a result, emacs would grow better acl support over time, and so would > the other packages using get_permissions and set_permissions. Like I said: a lot of work for too little a gain. I'm not volunteering, sorry. Emacs already has ACL support that is good enough for me. > >> As a side effect of that, cp in coreutils would then also do the right thing on > >> Windows (if someone made coreutils build there again). > > > > If cp just copies the ACLs, it doesn't need all this machinery. It > > just need to handle ACLs as an opaque object understood only by > > acl_get_file and acl_set_file. > > There's a bit more to copying acls if you want to copy between file > systems which > support different kinds of acls (or no acls) in a reasonable way. That problem doesn't exist on Windows, as ACLs are mapped to the same representation, no matter what the underlying filesystem. > It doesn't make a whole lot of sense to emulate Windows as POSIX > ACLs, and it makes no sense to emulate them as ACL_TYPE_ACCESS. It made a lot of sense to me at the time. Emacs (and other programs I'm interested in) comes from the Posix world, so its "mindset" is that of a Posix program. And the Posix APIs for manipulating ACLs are simple and well documented, so emulating them was easy. As for ACL_TYPE_ACCESS, since Emacs uses only one type of ACLs, it doesn't matter for an emulation how that type is identified. It's just a symbol. > > So I think the depth of compliance which is expected by > > set-permissions.c is too much for Windows, way beyond the proverbial > > 80-20 point. > > Adding Windows ACL support to get_permissions and set_permissions > really doesn't take a whole lot more than copying the code from emacs into > gnulib and testing the result. It's really not such a big deal. ??? If it were true, set-permissions.c would compile on Windows. It doesn't. So there's more to this job than just copying the code. > > There's also the minor (but important for Emacs) point of supporting > > file names with characters outside of the current system codepage, > > which Gnulib can only provide in UTF-8 locales, something that doesn't > > exist on Windows. > > This has nothing to do with get_permissions and set_permissions. It's a reason not to use Gnulib for any file-related operations in Emacs on Windows, because Emacs on Windows uses Unicode APIs to access files by their names.