GNU bug report logs -
#20681
Build failure [MSYS2/MINGW64, OSX]
Previous Next
Full log
View this message in rfc822 format
> Date: Mon, 1 Jun 2015 18:18:43 +0200
> From: Andreas Grünbacher <andreas.gruenbacher <at> gmail.com>
> Cc: Nick Andryshak <nandryshak <at> gmail.com>, 20681 <at> debbugs.gnu.org,
> Paul Eggert <eggert <at> cs.ucla.edu>, Angelo Graziosi <angelo.graziosi <at> alice.it>
>
> 2015-06-01 17:05 GMT+02:00 Eli Zaretskii <eliz <at> 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.
This bug report was last modified 9 years and 358 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.