GNU bug report logs -
#20681
Build failure [MSYS2/MINGW64, OSX]
Previous Next
Full log
Message #67 received at 20681 <at> debbugs.gnu.org (full text, mbox):
> 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 10 years and 43 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.