bug#20681: Build failure [MSYS2/MINGW64, OSX]

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 1 Jun 2015 18:18:43 +0200
> From: Andreas Grünbacher <andreas.gruenbacher@gmail.com>
> Cc: Nick Andryshak <nandryshak@gmail.com>, 20681@debbugs.gnu.org, 
> 	Paul Eggert <eggert@cs.ucla.edu>, Angelo Graziosi <angelo.graziosi@alice.it>
> 
> 2015-06-01 17:05 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:
> >> 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.