(call-process ...) hangs in emacs
Tue Sep 2 20:09:00 GMT 2014
On Sep 2 21:42, Achim Gratz wrote:
> Corinna Vinschen writes:
> > More or less, just compare the ACLs and see if you find strange
> > differences. This only works for the ACLs created or modified with
> > `setfacl' and the snapshot DLL.
> I see, I'll have to make extra tests for this. Usually I just have to
> live with some inherited ACL that I can't change at all.
> > The ACLs created or modified via
> > setfacl with the older DLLs always were different and, I have to admit,
> > kind of broke the default POSIX permissions created via open() or
> > chmod(). The idea of my change was to make them always in an identical
> > fashion. The order may only vary in secondary permissions, but never
> > in the standard permissions, which also always come first.
> One thing I've noticed, but can't really say if it's related to the
> change, is that setfacl quite often claims an "illegal ACL" when trying
> to remove for instance the SYSTEM read permission.
$ setfacl -d g:system: filename
Note the trailing colon.
> Removing the group
> owner ACL instead did the right thing in at least one instance.
??? It shouldn't. Removing the standard ACL entries for the owner,
owner group, and other is not allowed:
$ setfacl -d g:: filename
setfacl: No error
The "No error" is a bug, related to the fact that the aclsort() function
doesn't set errno if aclcheck() failed. I just fixed that in CVS.
> I've mostly been removing all ACL from the whole tree via the explorer
> security tab (for ~/.ssh/ and similar stuff).
*All* ACL??? That sounds wrong to me.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Cygwin