On Dec 22 15:42, Houder wrote: > On 2015-12-22 12:37, Houder wrote: > >On 2015-12-21 18:25, Corinna Vinschen wrote: > >>On Dec 21 17:30, Houder wrote: > >>>Hi Corinna, > >>> > >>>For next year !!!!! (posted as a reminder) ... See below. > >> > >>Next year? Nope... see below. > >> > > > >Hi Corinna, > > > >Thank you for all the hard work you do ... > > > >As an encore (for this year though ;-). See below (Cygwin-2.4.0-0.16). > ><==== 16 > [snip] > > >64-%% setfacl -m m:rwx bar.txt > >64-%% getfacl bar.txt > ># file: bar.txt > ># owner: Henri > ># group: None > >user::rw- > >group::r-- > >mask:rwx <==== yes, as requested by me, but ... > >other:r-- > > > >64-%% ls -l bar.txt > >-rw-rwxr-- 1 Henri None 0 Dec 22 12:21 bar.txt > > > > - does this output make sense? > > (no access to Linux at the moment; cannot verify) > > Just got myself access to Linux (FC19) ... old, yes. > > FC19 has the same "weird" (to me) behaviour as Cygwin now has.
It's correct. The rule is that the group perms reflect the mask if a mask is present, the primary group perms otherwise. > The > difference is that 'ls -l' on FC19 shows an additional plus sign. This is a problem in ls itself. The reason is that with the start of reimplementing the ACL handling (back in August 2014), the definition of MIN_ACL_ENTRIES changed from 4 to 3. I recall having a discussion with eblake (coreutils maintainer) via IRC in 2014 where we discussed this. At that time the mask entry was only fasked, so we came up with the fact that there's never an aclent_t with 4 entries, so ls is still using the old definition to maintain backward compat. With the new code in 2.4.0 it's probably time to drop this Cygwin-specific workaround in coreutils (but it doesn't hurt much either). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
signature.asc
Description: PGP signature
