Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.8

2015-12-08 Thread Corinna Vinschen 
On Dec  7 21:30, Kacper Michajlow wrote:
> 2015-12-07 17:00 GMT+01:00 Corinna Vinschen :
> > On Dec  7 10:37, Corinna Vinschen wrote:
> >> On Dec  6 21:21, Kacper Michajlow wrote:
> >> > 2015-12-06 19:57 GMT+01:00 Corinna Vinschen :
> >> > > Hi Cygwin friends and users,
> >> > >
> >> > >
> >> > > I released a new TEST version of Cygwin, 2.4.0-0.8.
> >> > > [...]
> >> > Since 2015-12-03 snapshot I got only black screen when running this 
> >> > batch script
> >> > @echo off
> >> > C:
> >> > chdir C:\cygwin\bin
> >> > zsh -l -i
> >> >
> >> > Basically it deadlocks while processing .zshrc. I was debugging this
> >> > and it locks when loading "oh my zsh".
> >> >
> >> > Long story short is seems to hang here
> >> > https://github.com/robbyrussell/oh-my-zsh/blob/master/lib/git.zsh#L177
> >> > at least for the first time, because if I remove this line it hangs
> >> > somewhere else. It basically hangs if in git_compare_version() is any
> >> > kind of external command which cause fork.
> >> >
> >> > It works fine when running from mintty.
> >>
> >> Confirmed.  I have two different ways to fix this, but I'm not sure yet
> >> which one is better.  I'll test them a bit and probably check one of
> >> them in later today.
> >
> > I just uploaded a new developer snapshot to https://cygwin.com/snapshots/
> > and I just announced a new test release 2.4.0-0.9,
> > https://cygwin.com/ml/cygwin-announce/2015-12/msg7.html, both of
> > which come with a patch which should fix this issue.  It did for me, at
> > least :}
> >
> > Please give any of them a try.
> 
> 2.4.0-0.9 works fine. Thanks.

Thanks for testing and your feedback.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpg_kBiIFH35.pgp
Description: PGP signature

Re: TEST RELEASE: Cygwin 2.4.0-0.8

2015-12-07 Thread Jim Reisert AD1C 
> [Corinna] released a new TEST version of Cygwin, 2.4.0-0.8.

It's been over 24 hours, and the 64-bit version has not yet appeared
on http://mirrors.xmission.com.  The 32-bit version is available on
go-parts.com, however.

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: TEST RELEASE: Cygwin 2.4.0-0.8

2015-12-07 Thread Corinna Vinschen 
On Dec  7 08:45, Jim Reisert AD1C wrote:
> > [Corinna] released a new TEST version of Cygwin, 2.4.0-0.8.
> 
> It's been over 24 hours, and the 64-bit version has not yet appeared
> on http://mirrors.xmission.com.  The 32-bit version is available on
> go-parts.com, however.

We don't control the mirrors.  I just uploaded a new 2.4.0-0.9 test
release, though, and I'm sure it's on sourceware.org so it should hit
the mirrors soon.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpm0aZehJl6k.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.8

2015-12-07 Thread Corinna Vinschen 
On Dec  7 10:37, Corinna Vinschen wrote:
> On Dec  6 21:21, Kacper Michajlow wrote:
> > 2015-12-06 19:57 GMT+01:00 Corinna Vinschen :
> > > Hi Cygwin friends and users,
> > >
> > >
> > > I released a new TEST version of Cygwin, 2.4.0-0.8.
> > > [...]
> > Since 2015-12-03 snapshot I got only black screen when running this batch 
> > script
> > @echo off
> > C:
> > chdir C:\cygwin\bin
> > zsh -l -i
> > 
> > Basically it deadlocks while processing .zshrc. I was debugging this
> > and it locks when loading "oh my zsh".
> > 
> > Long story short is seems to hang here
> > https://github.com/robbyrussell/oh-my-zsh/blob/master/lib/git.zsh#L177
> > at least for the first time, because if I remove this line it hangs
> > somewhere else. It basically hangs if in git_compare_version() is any
> > kind of external command which cause fork.
> > 
> > It works fine when running from mintty.
> 
> Confirmed.  I have two different ways to fix this, but I'm not sure yet
> which one is better.  I'll test them a bit and probably check one of
> them in later today.

I just uploaded a new developer snapshot to https://cygwin.com/snapshots/
and I just announced a new test release 2.4.0-0.9,
https://cygwin.com/ml/cygwin-announce/2015-12/msg7.html, both of
which come with a patch which should fix this issue.  It did for me, at
least :}

Please give any of them a try.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpAMz77kApwN.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.8

2015-12-07 Thread Corinna Vinschen 
On Dec  6 21:21, Kacper Michajlow wrote:
> 2015-12-06 19:57 GMT+01:00 Corinna Vinschen :
> > Hi Cygwin friends and users,
> >
> >
> > I released a new TEST version of Cygwin, 2.4.0-0.8.
> >
> > This adds a new feature to cygpath, the -U flag, which allows to
> > generate /proc/cygdrive paths, which are unambiguous even if the
> > cygdrive prefix changes.  E.g.:
> >
> >   $ mount -p
> >   Prefix  Type Flags
> >   /mntuser binmode
> >
> >   $ cygpath -D
> >   /mnt/c/Users/corinna/Desktop
> >
> >   $ ./cygpath -DU
> >   /proc/cygdrive/c/Users/corinna/Desktop
> >
> > I'd like to point out the Windows 10 1511 workaround added to 2.4.0-0.7
> > again since it's important that it gets tested:
> >
> > - Not a bug fix as such, but a workaround for new behaviour in Windows 10
> >   version 1511 64 bit.  This version introduces a problem which existed in
> >   a similar variation (just vice versa) in XP and Server 2003 64 bit as 
> > well.
> >   An unexpected stack arrangement when starting a 64 bit Cygwin application
> >   from a 32 bit application (e.g. 32 bit CMD.EXE) broke Cygwin's fork.
> >   Addresses: https://cygwin.com/ml/cygwin/2015-12/msg3.html
> > [...]
> 
> Hi,
> 
> Since 2015-12-03 snapshot I got only black screen when running this batch 
> script
> @echo off
> C:
> chdir C:\cygwin\bin
> zsh -l -i
> 
> Basically it deadlocks while processing .zshrc. I was debugging this
> and it locks when loading "oh my zsh".
> 
> Long story short is seems to hang here
> https://github.com/robbyrussell/oh-my-zsh/blob/master/lib/git.zsh#L177
> at least for the first time, because if I remove this line it hangs
> somewhere else. It basically hangs if in git_compare_version() is any
> kind of external command which cause fork.
> 
> It works fine when running from mintty.

Confirmed.  I have two different ways to fix this, but I'm not sure yet
which one is better.  I'll test them a bit and probably check one of
them in later today.


Thanks a lot for testing,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpBUS1b0W1Gh.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.8

2015-12-07 Thread Kacper Michajlow 
2015-12-07 17:00 GMT+01:00 Corinna Vinschen :
> On Dec  7 10:37, Corinna Vinschen wrote:
>> On Dec  6 21:21, Kacper Michajlow wrote:
>> > 2015-12-06 19:57 GMT+01:00 Corinna Vinschen :
>> > > Hi Cygwin friends and users,
>> > >
>> > >
>> > > I released a new TEST version of Cygwin, 2.4.0-0.8.
>> > > [...]
>> > Since 2015-12-03 snapshot I got only black screen when running this batch 
>> > script
>> > @echo off
>> > C:
>> > chdir C:\cygwin\bin
>> > zsh -l -i
>> >
>> > Basically it deadlocks while processing .zshrc. I was debugging this
>> > and it locks when loading "oh my zsh".
>> >
>> > Long story short is seems to hang here
>> > https://github.com/robbyrussell/oh-my-zsh/blob/master/lib/git.zsh#L177
>> > at least for the first time, because if I remove this line it hangs
>> > somewhere else. It basically hangs if in git_compare_version() is any
>> > kind of external command which cause fork.
>> >
>> > It works fine when running from mintty.
>>
>> Confirmed.  I have two different ways to fix this, but I'm not sure yet
>> which one is better.  I'll test them a bit and probably check one of
>> them in later today.
>
> I just uploaded a new developer snapshot to https://cygwin.com/snapshots/
> and I just announced a new test release 2.4.0-0.9,
> https://cygwin.com/ml/cygwin-announce/2015-12/msg7.html, both of
> which come with a patch which should fix this issue.  It did for me, at
> least :}
>
> Please give any of them a try.

2.4.0-0.9 works fine. Thanks.

-Kacper

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

TEST RELEASE: Cygwin 2.4.0-0.8

2015-12-06 Thread Corinna Vinschen 
Hi Cygwin friends and users,


I released a new TEST version of Cygwin, 2.4.0-0.8.

This adds a new feature to cygpath, the -U flag, which allows to
generate /proc/cygdrive paths, which are unambiguous even if the
cygdrive prefix changes.  E.g.:

  $ mount -p
  Prefix  Type Flags
  /mntuser binmode

  $ cygpath -D
  /mnt/c/Users/corinna/Desktop

  $ ./cygpath -DU
  /proc/cygdrive/c/Users/corinna/Desktop

I'd like to point out the Windows 10 1511 workaround added to 2.4.0-0.7
again since it's important that it gets tested:

- Not a bug fix as such, but a workaround for new behaviour in Windows 10
  version 1511 64 bit.  This version introduces a problem which existed in
  a similar variation (just vice versa) in XP and Server 2003 64 bit as well.
  An unexpected stack arrangement when starting a 64 bit Cygwin application
  from a 32 bit application (e.g. 32 bit CMD.EXE) broke Cygwin's fork.
  Addresses: https://cygwin.com/ml/cygwin/2015-12/msg3.html


==

Please, please, please test.

If this code is acceptable, I will create an official 2.4.0 release
next week.

==
 

This is the "new POSIX ACL handling reloaded" release.

In local testing I successfully integrated AuthZ into the current Cygwin
code to generate more correct user permissions by being able to generate
effective permissions for arbitrary users.

This success convinced me that it might be possible to pick up the POSIX
permission rewrite originally targeted for the 2.0.0 release and try to
update it using AuthZ and generally revamp it to reflect effective
permissions better.

My local testing looks good, but this is a major change, so this code
really needs a lot more testing in various scenarios.  Especially
some Windows ACLs created in corporate environments are often a hard
nut to crack, and the example from

https://cygwin.com/ml/cygwin/2015-04/msg00513.html

which was the ultimate downfall of the original implementation is
the stuff which needs some good testing.

There's, as usual, a downside: AuthZ leans a bit to the slow side.
Cygwin caches information already gathered once on a per-process basis,
but in locally crafted worst case scenarios (`ls' on lots of file owned
by lots of different users and groups) the slowdown may be up to 25%.
But that's really just a worst case, in the usual scenarios the slowdown
should be mostly unnoticable.

To alleviate the problem, the AuthZ code is fortunately only called for
non-Cygwin ACLs and Cygwin ACLs created before this release.  Within a
pure Cygwin environment (e.g., some build directory only used with
Cygwin tools) AuthZ should be practically unused.

Apart from the aforementioned code changes to "just do it right", there
are two additional changes I implemented for this new POSIX ACL revamp
release:

- I reverted the questionable change I added to 2.0.0-0.7 in terms of
  chmod group permission handling.  The original description of this
  change was:

If you have a non-trivial ACL with secondary accounts and thus a
mask value, chmod is supposed to change only the mask, not the
permissions of the primary group.  However, if the primary group has
few permissions to begin with, the result is really surprising.  ls
-l would, e.g., show read/write perms for the group, but the group
might still have only read perms.

Personally I find this chmod behaviour really, really bad, so I took
the liberty to change it in a way which gives a much less surprising
result:  If you call chmod on a non-trivial ACL, the group
permissions will be used for the primary group and the mask.

- setfacl(1) now accepts the combination of the -b and -k options, just as
  on Linux.

As for the description what this implementation strives for, please see
http://linux.die.net/man/5/acl



What's new:
---

- New, unified implementation of POSIX permission and ACL handling.  The
  new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and
  they allow to inherit the S_ISGID bit.  ACL inheritance now really
  works as desired, in a limited, but theoretically equivalent fashion
  even for non-Cygwin processes.

  To accommodate standard Windows ACLs, the POSIX permissions of the
  owner and all other users in the ACL are computed using the Windows
  AuthZ API.  This may slow down the computation of POSIX permissions
  noticably in some circumstances, but is generally more correct.  The
  new code also ignores SYSTEM and Administrators group permissions when
  computing the MASK/CLASS_OBJ permission mask on old ACLs, and it
  doesn't deny access to SYSTEM and Administrators group based on the
  value of MASK/CLASS_OBJ when creating the new ACLs.

  The new code now handles the S_ISGID bit on directories as on Linux:

[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.8

2015-12-06 Thread Corinna Vinschen 
Hi Cygwin friends and users,


I released a new TEST version of Cygwin, 2.4.0-0.8.

This adds a new feature to cygpath, the -U flag, which allows to
generate /proc/cygdrive paths, which are unambiguous even if the
cygdrive prefix changes.  E.g.:

  $ mount -p
  Prefix  Type Flags
  /mntuser binmode

  $ cygpath -D
  /mnt/c/Users/corinna/Desktop

  $ ./cygpath -DU
  /proc/cygdrive/c/Users/corinna/Desktop

I'd like to point out the Windows 10 1511 workaround added to 2.4.0-0.7
again since it's important that it gets tested:

- Not a bug fix as such, but a workaround for new behaviour in Windows 10
  version 1511 64 bit.  This version introduces a problem which existed in
  a similar variation (just vice versa) in XP and Server 2003 64 bit as well.
  An unexpected stack arrangement when starting a 64 bit Cygwin application
  from a 32 bit application (e.g. 32 bit CMD.EXE) broke Cygwin's fork.
  Addresses: https://cygwin.com/ml/cygwin/2015-12/msg3.html


==

Please, please, please test.

If this code is acceptable, I will create an official 2.4.0 release
next week.

==
 

This is the "new POSIX ACL handling reloaded" release.

In local testing I successfully integrated AuthZ into the current Cygwin
code to generate more correct user permissions by being able to generate
effective permissions for arbitrary users.

This success convinced me that it might be possible to pick up the POSIX
permission rewrite originally targeted for the 2.0.0 release and try to
update it using AuthZ and generally revamp it to reflect effective
permissions better.

My local testing looks good, but this is a major change, so this code
really needs a lot more testing in various scenarios.  Especially
some Windows ACLs created in corporate environments are often a hard
nut to crack, and the example from

https://cygwin.com/ml/cygwin/2015-04/msg00513.html

which was the ultimate downfall of the original implementation is
the stuff which needs some good testing.

There's, as usual, a downside: AuthZ leans a bit to the slow side.
Cygwin caches information already gathered once on a per-process basis,
but in locally crafted worst case scenarios (`ls' on lots of file owned
by lots of different users and groups) the slowdown may be up to 25%.
But that's really just a worst case, in the usual scenarios the slowdown
should be mostly unnoticable.

To alleviate the problem, the AuthZ code is fortunately only called for
non-Cygwin ACLs and Cygwin ACLs created before this release.  Within a
pure Cygwin environment (e.g., some build directory only used with
Cygwin tools) AuthZ should be practically unused.

Apart from the aforementioned code changes to "just do it right", there
are two additional changes I implemented for this new POSIX ACL revamp
release:

- I reverted the questionable change I added to 2.0.0-0.7 in terms of
  chmod group permission handling.  The original description of this
  change was:

If you have a non-trivial ACL with secondary accounts and thus a
mask value, chmod is supposed to change only the mask, not the
permissions of the primary group.  However, if the primary group has
few permissions to begin with, the result is really surprising.  ls
-l would, e.g., show read/write perms for the group, but the group
might still have only read perms.

Personally I find this chmod behaviour really, really bad, so I took
the liberty to change it in a way which gives a much less surprising
result:  If you call chmod on a non-trivial ACL, the group
permissions will be used for the primary group and the mask.

- setfacl(1) now accepts the combination of the -b and -k options, just as
  on Linux.

As for the description what this implementation strives for, please see
http://linux.die.net/man/5/acl



What's new:
---

- New, unified implementation of POSIX permission and ACL handling.  The
  new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and
  they allow to inherit the S_ISGID bit.  ACL inheritance now really
  works as desired, in a limited, but theoretically equivalent fashion
  even for non-Cygwin processes.

  To accommodate standard Windows ACLs, the POSIX permissions of the
  owner and all other users in the ACL are computed using the Windows
  AuthZ API.  This may slow down the computation of POSIX permissions
  noticably in some circumstances, but is generally more correct.  The
  new code also ignores SYSTEM and Administrators group permissions when
  computing the MASK/CLASS_OBJ permission mask on old ACLs, and it
  doesn't deny access to SYSTEM and Administrators group based on the
  value of MASK/CLASS_OBJ when creating the new ACLs.

  The new code now handles the S_ISGID bit on directories as on Linux:

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.8

2015-12-06 Thread Kacper Michajlow 
2015-12-06 19:57 GMT+01:00 Corinna Vinschen :
> Hi Cygwin friends and users,
>
>
> I released a new TEST version of Cygwin, 2.4.0-0.8.
>
> This adds a new feature to cygpath, the -U flag, which allows to
> generate /proc/cygdrive paths, which are unambiguous even if the
> cygdrive prefix changes.  E.g.:
>
>   $ mount -p
>   Prefix  Type Flags
>   /mntuser binmode
>
>   $ cygpath -D
>   /mnt/c/Users/corinna/Desktop
>
>   $ ./cygpath -DU
>   /proc/cygdrive/c/Users/corinna/Desktop
>
> I'd like to point out the Windows 10 1511 workaround added to 2.4.0-0.7
> again since it's important that it gets tested:
>
> - Not a bug fix as such, but a workaround for new behaviour in Windows 10
>   version 1511 64 bit.  This version introduces a problem which existed in
>   a similar variation (just vice versa) in XP and Server 2003 64 bit as well.
>   An unexpected stack arrangement when starting a 64 bit Cygwin application
>   from a 32 bit application (e.g. 32 bit CMD.EXE) broke Cygwin's fork.
>   Addresses: https://cygwin.com/ml/cygwin/2015-12/msg3.html
>
>
> ==
>
> Please, please, please test.
>
> If this code is acceptable, I will create an official 2.4.0 release
> next week.
>
> ==
>
>
> This is the "new POSIX ACL handling reloaded" release.
>
> In local testing I successfully integrated AuthZ into the current Cygwin
> code to generate more correct user permissions by being able to generate
> effective permissions for arbitrary users.
>
> This success convinced me that it might be possible to pick up the POSIX
> permission rewrite originally targeted for the 2.0.0 release and try to
> update it using AuthZ and generally revamp it to reflect effective
> permissions better.
>
> My local testing looks good, but this is a major change, so this code
> really needs a lot more testing in various scenarios.  Especially
> some Windows ACLs created in corporate environments are often a hard
> nut to crack, and the example from
>
> https://cygwin.com/ml/cygwin/2015-04/msg00513.html
>
> which was the ultimate downfall of the original implementation is
> the stuff which needs some good testing.
>
> There's, as usual, a downside: AuthZ leans a bit to the slow side.
> Cygwin caches information already gathered once on a per-process basis,
> but in locally crafted worst case scenarios (`ls' on lots of file owned
> by lots of different users and groups) the slowdown may be up to 25%.
> But that's really just a worst case, in the usual scenarios the slowdown
> should be mostly unnoticable.
>
> To alleviate the problem, the AuthZ code is fortunately only called for
> non-Cygwin ACLs and Cygwin ACLs created before this release.  Within a
> pure Cygwin environment (e.g., some build directory only used with
> Cygwin tools) AuthZ should be practically unused.
>
> Apart from the aforementioned code changes to "just do it right", there
> are two additional changes I implemented for this new POSIX ACL revamp
> release:
>
> - I reverted the questionable change I added to 2.0.0-0.7 in terms of
>   chmod group permission handling.  The original description of this
>   change was:
>
> If you have a non-trivial ACL with secondary accounts and thus a
> mask value, chmod is supposed to change only the mask, not the
> permissions of the primary group.  However, if the primary group has
> few permissions to begin with, the result is really surprising.  ls
> -l would, e.g., show read/write perms for the group, but the group
> might still have only read perms.
>
> Personally I find this chmod behaviour really, really bad, so I took
> the liberty to change it in a way which gives a much less surprising
> result:  If you call chmod on a non-trivial ACL, the group
> permissions will be used for the primary group and the mask.
>
> - setfacl(1) now accepts the combination of the -b and -k options, just as
>   on Linux.
>
> As for the description what this implementation strives for, please see
> http://linux.die.net/man/5/acl
>
> 
>
> What's new:
> ---
>
> - New, unified implementation of POSIX permission and ACL handling.  The
>   new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and
>   they allow to inherit the S_ISGID bit.  ACL inheritance now really
>   works as desired, in a limited, but theoretically equivalent fashion
>   even for non-Cygwin processes.
>
>   To accommodate standard Windows ACLs, the POSIX permissions of the
>   owner and all other users in the ACL are computed using the Windows
>   AuthZ API.  This may slow down the computation of POSIX permissions
>   noticably in some circumstances, but is generally more correct.  The
>   new code also ignores SYSTEM and Administrators group permissions

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.8

2015-12-06 Thread Kacper Michajlow 
I forgot to say. I'm running Windows 10 1511 x64.

2015-12-06 21:21 GMT+01:00 Kacper Michajlow :
> 2015-12-06 19:57 GMT+01:00 Corinna Vinschen :
>> Hi Cygwin friends and users,
>>
>>
>> I released a new TEST version of Cygwin, 2.4.0-0.8.
>>
>> This adds a new feature to cygpath, the -U flag, which allows to
>> generate /proc/cygdrive paths, which are unambiguous even if the
>> cygdrive prefix changes.  E.g.:
>>
>>   $ mount -p
>>   Prefix  Type Flags
>>   /mntuser binmode
>>
>>   $ cygpath -D
>>   /mnt/c/Users/corinna/Desktop
>>
>>   $ ./cygpath -DU
>>   /proc/cygdrive/c/Users/corinna/Desktop
>>
>> I'd like to point out the Windows 10 1511 workaround added to 2.4.0-0.7
>> again since it's important that it gets tested:
>>
>> - Not a bug fix as such, but a workaround for new behaviour in Windows 10
>>   version 1511 64 bit.  This version introduces a problem which existed in
>>   a similar variation (just vice versa) in XP and Server 2003 64 bit as well.
>>   An unexpected stack arrangement when starting a 64 bit Cygwin application
>>   from a 32 bit application (e.g. 32 bit CMD.EXE) broke Cygwin's fork.
>>   Addresses: https://cygwin.com/ml/cygwin/2015-12/msg3.html
>>
>>
>> ==
>>
>> Please, please, please test.
>>
>> If this code is acceptable, I will create an official 2.4.0 release
>> next week.
>>
>> ==
>>
>>
>> This is the "new POSIX ACL handling reloaded" release.
>>
>> In local testing I successfully integrated AuthZ into the current Cygwin
>> code to generate more correct user permissions by being able to generate
>> effective permissions for arbitrary users.
>>
>> This success convinced me that it might be possible to pick up the POSIX
>> permission rewrite originally targeted for the 2.0.0 release and try to
>> update it using AuthZ and generally revamp it to reflect effective
>> permissions better.
>>
>> My local testing looks good, but this is a major change, so this code
>> really needs a lot more testing in various scenarios.  Especially
>> some Windows ACLs created in corporate environments are often a hard
>> nut to crack, and the example from
>>
>> https://cygwin.com/ml/cygwin/2015-04/msg00513.html
>>
>> which was the ultimate downfall of the original implementation is
>> the stuff which needs some good testing.
>>
>> There's, as usual, a downside: AuthZ leans a bit to the slow side.
>> Cygwin caches information already gathered once on a per-process basis,
>> but in locally crafted worst case scenarios (`ls' on lots of file owned
>> by lots of different users and groups) the slowdown may be up to 25%.
>> But that's really just a worst case, in the usual scenarios the slowdown
>> should be mostly unnoticable.
>>
>> To alleviate the problem, the AuthZ code is fortunately only called for
>> non-Cygwin ACLs and Cygwin ACLs created before this release.  Within a
>> pure Cygwin environment (e.g., some build directory only used with
>> Cygwin tools) AuthZ should be practically unused.
>>
>> Apart from the aforementioned code changes to "just do it right", there
>> are two additional changes I implemented for this new POSIX ACL revamp
>> release:
>>
>> - I reverted the questionable change I added to 2.0.0-0.7 in terms of
>>   chmod group permission handling.  The original description of this
>>   change was:
>>
>> If you have a non-trivial ACL with secondary accounts and thus a
>> mask value, chmod is supposed to change only the mask, not the
>> permissions of the primary group.  However, if the primary group has
>> few permissions to begin with, the result is really surprising.  ls
>> -l would, e.g., show read/write perms for the group, but the group
>> might still have only read perms.
>>
>> Personally I find this chmod behaviour really, really bad, so I took
>> the liberty to change it in a way which gives a much less surprising
>> result:  If you call chmod on a non-trivial ACL, the group
>> permissions will be used for the primary group and the mask.
>>
>> - setfacl(1) now accepts the combination of the -b and -k options, just as
>>   on Linux.
>>
>> As for the description what this implementation strives for, please see
>> http://linux.die.net/man/5/acl
>>
>> 
>>
>> What's new:
>> ---
>>
>> - New, unified implementation of POSIX permission and ACL handling.  The
>>   new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and
>>   they allow to inherit the S_ISGID bit.  ACL inheritance now really
>>   works as desired, in a limited, but theoretically equivalent fashion
>>   even for non-Cygwin processes.
>>
>>   To accommodate standard Windows ACLs, the POSIX permissions of the
>>   owner and all other users in the ACL are computed