[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13226: 24.3.50; set-file-acl on MS Windows shall check ACL string fo
From: |
Eli Zaretskii |
Subject: |
bug#13226: 24.3.50; set-file-acl on MS Windows shall check ACL string format |
Date: |
Wed, 19 Dec 2012 18:33:22 +0200 |
> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Wed, 19 Dec 2012 09:32:36 -0500
> Cc: 13226@debbugs.gnu.org
>
> > (file-acl "~/.emacs")
>
> > "O:S-1-5-21-3955186872-1115707380-970145838-1000G:S-1-5-21-3955186872-1115707380-970145838-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-3955186872-1115707380-970145838-1000)"
>
> This looks thoroughly unportable.
It is explicitly documented as platform-specific in the ELisp manual.
Once again, the original design had a modest goal: allow to copy these
attributes from file to file. Are you sure we want to extend that to
a much more complex system which would allow a Lisp program to
interpret those strings in a platform-independent manner?
> We should probably change file-acl so that its return value is tagged
> with the "acl-system" it uses. It could be a prefix like "w32:".
As I wrote elsewhere, I don't see the rationale.
> Then we can change set-file-acl so that it can either try to perform
> conversion or signal a proper error that copy-file can handle.
copy-file the primitive is not affected, it already does TRT with this
scenario. copy-file handler for remote files should simply catch and
ignore the errors, like the primitive does.
bug#13226: 24.3.50; set-file-acl on MS Windows shall check ACL string format, Stefan Monnier, 2012/12/19
bug#13226: 24.3.50; set-file-acl on MS Windows shall check ACL string format, Eli Zaretskii, 2012/12/19