[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Corinna Vinschen]

Hi Cygwin friends and users,


I released a new TEST version of Cygwin, 2.3.0-0.4.

This test release contains all Cygwin-related patches applied during
and after my vacation.  Other than that, the original intention,
testing the "new POSIX ACL handling reloaded" code, still applies.

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 (here's looking at you Achim ;)).

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

All changes in this release so far:

============================================================================

What's new:
-----------

- posix_madvise(POSIX_MADV_WILLNEED) now utilizes OS functionality available
  starting with Windows 8/Server 2012.  Still a no-op on older systems.

- posix_madvise(POSIX_MADV_DONTNEED) now utilizes OS functionality available
  starting with Windows 8.1/Server 2012R2.  Still a no-op on older systems.

- sysconf() now supports returning CPU cache information:
  _SC_LEVEL1_ICACHE_SIZE, _SC_LEVEL1_ICACHE_ASSOC, _SC_LEVEL1_ICACHE_LINESIZE,
  _SC_LEVEL1_DCACHE_SIZE, _SC_LEVEL1_DCACHE_ASSOC, _SC_LEVEL1_DCACHE_LINESIZE,
  _SC_LEVEL2_CACHE_SIZE, _SC_LEVEL2_CACHE_ASSOC, _SC_LEVEL2_CACHE_LINESIZE,
  _SC_LEVEL3_CACHE_SIZE, _SC_LEVEL3_CACHE_ASSOC, _SC_LEVEL3_CACHE_LINESIZE,
  _SC_LEVEL4_CACHE_SIZE, _SC_LEVEL4_CACHE_ASSOC, _SC_LEVEL4_CACHE_LINESIZE

- New API: aligned_alloc, at_quick_exit, quick_exit.


What changed:
-------------

- setfacl(1) now allows to use the -b and -k option combined to allow reducing
  an ACL to only reflect standard POSIX permissions.


Bug Fixes
---------

- Fix a hang when stracing a forking or spawning process without activating
  stracing of child processes.
  Addresses: https://cygwin.com/ml/cygwin/2015-08/msg00390.html

- Fix long-standing potential SEGV on 32 bit Cygwin when the dynamic loader
  for OS functions fails to load a function on Windows 7 or later.
  Addresses: No actual bug report known.

- sysconf _SC_NPROCESSORS_CONF and _SC_NPROCESSORS_ONLN now handle more than
  64 CPUs on Windows 7 and later.

- Fix a potential crash in advisory file locking due to usage of stack space
  out of scope.
  Addresses: https://cygwin.com/ml/cygwin/2015-09/msg00079.html

- Fix EIO error accessing certain (OS X SMB?) drives
  Addresses: https://cygwin.com/ml/cygwin/2015-09/msg00229.html

- Fix memory leak in calls to pthread_getattr_np.

- Fix output of /proc/<PID>/winexename.

- Avoid SEGV when handling SIDs with 0 subauthorities.
  Addresses: https://cygwin.com/ml/cygwin/2015-10/msg00141.html

============================================================================


Have fun,
Corinna

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

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Achim Gratz]

I don't have much time to test it right now (and won't have any time at all
next week), but so far things look good.  The problem with the 0.2 test
version with UID/GID mapping and not recognizing the primary domain in some
cases is gone (might have been a fluke anyway).  Correlating the output from
getfacl and icacls still requires some mental gymnastics, but I didn't find
any obvious errors in the mode bits and ACL so far, which means that things
like rsync (and some file tests) will now return the correct results for the
cases I've looked at.


Regards,
Achim.




--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

On Oct 23 11:06, Achim Gratz wrote:
> I don't have much time to test it right now (and won't have any time at all
> next week), but so far things look good.  The problem with the 0.2 test
> version with UID/GID mapping and not recognizing the primary domain in some
> cases is gone (might have been a fluke anyway).  Correlating the output from
> getfacl and icacls still requires some mental gymnastics, but I didn't find
> any obvious errors in the mode bits and ACL so far, which means that things
> like rsync (and some file tests) will now return the correct results for the
> cases I've looked at.

You won't believe how grateful I am having you testing this.  Thank you!

Would you mind to read the comment at the start of sec_acl.cc?  I'd be
very interested in learning if the description is meaningful enough to
other developers.  I also fear we need to have an improved documentation
explaining how this works and what NOT to do, e.g., reorder ACLs :|


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

On Oct 23 14:22, Corinna Vinschen wrote:
> On Oct 23 11:06, Achim Gratz wrote:
> > I don't have much time to test it right now (and won't have any time at all
> > next week), but so far things look good.  The problem with the 0.2 test
> > version with UID/GID mapping and not recognizing the primary domain in some
> > cases is gone (might have been a fluke anyway).  Correlating the output from
> > getfacl and icacls still requires some mental gymnastics, but I didn't find
> > any obvious errors in the mode bits and ACL so far, which means that things
> > like rsync (and some file tests) will now return the correct results for the
> > cases I've looked at.
> 
> You won't believe how grateful I am having you testing this.  Thank you!
> 
> Would you mind to read the comment at the start of sec_acl.cc?

https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/sec_acl.cc;hb=a8ec1e804ee9ba2d6f8304731e593dcf167c9836#l27

> I'd be
> very interested in learning if the description is meaningful enough to
> other developers.  I also fear we need to have an improved documentation
> explaining how this works and what NOT to do, e.g., reorder ACLs :|

Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> There's, as usual, a downside: AuthZ leans a bit to the slow side.

It's not too bad, as long as your network connection is fast (and fast means
short roundtrip time for an AD query).  If I take each page fault as
reported by time as a proxy for an AD access, then it needs about three
times more roundtrips to the AD.

On a server with almost perfect connectivity to the AD that increases the
wall-time of listing a very large directory with directories/files from many
users (about a quarter of all users in the AD, and not all from the local
domain) from 8 to 10 minutes.  The CPU time as well as the network traffic
is neglible in both cases.

On my local laptop things look a bit different, a small ~5% subset of the
test above goes from 20s to 200s and a different larger ~10% subset from 50s
to 500s.  While that hurts, the more usual case with many files from the
same user doesn't feel any slower at the moment.  The access through VPN
will be interesting, though...


Regards,
Achim.


--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

On Oct 23 14:01, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > There's, as usual, a downside: AuthZ leans a bit to the slow side.
> 
> It's not too bad, as long as your network connection is fast (and fast means
> short roundtrip time for an AD query).  If I take each page fault as
> reported by time as a proxy for an AD access, then it needs about three
> times more roundtrips to the AD.
> 
> On a server with almost perfect connectivity to the AD that increases the
> wall-time of listing a very large directory with directories/files from many
> users (about a quarter of all users in the AD, and not all from the local
> domain) from 8 to 10 minutes.  The CPU time as well as the network traffic
> is neglible in both cases.
> 
> On my local laptop things look a bit different, a small ~5% subset of the
> test above goes from 20s to 200s and a different larger ~10% subset from 50s
> to 500s.

Erm, really?  I tested this locally with a directory with hundreds
of files, each of which belonged to another user or group, and that
resulted in a 25% slowdown.  Not 1000%.  Oh boy.

> While that hurts, the more usual case with many files from the
> same user doesn't feel any slower at the moment.  The access through VPN
> will be interesting, though...

Did you try this in the meantime?

Given the above result, I'm wondering if we can afford using AuthZ at
all.  OTOH I don't see any other way to get the correct POSIX permissions
from a non-Cygwin ACL :(


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Achim Gratz]

Am 26.10.2015 um 11:07 schrieb Corinna Vinschen:
> Erm, really?  I tested this locally with a directory with hundreds
> of files, each of which belonged to another user or group, and that
> resulted in a 25% slowdown.  Not 1000%.  Oh boy.

That test is almost as bad as it can ever get.  Given that enumerating 
all AD accouts with mkpasswd takes about 2 hours and I'm doing something 
very similar here, I'm not even surprised.  I was more surprised to see 
the server go so fast, but my guess is that it can use jumbo frames to 
talk to the AD.

>> While that hurts, the more usual case with many files from the
>> same user doesn't feel any slower at the moment.  The access through VPN
>> will be interesting, though...
>
> Did you try this in the meantime?

No, sorry.

> Given the above result, I'm wondering if we can afford using AuthZ at
> all.  OTOH I don't see any other way to get the correct POSIX permissions
> from a non-Cygwin ACL :(

If you really want fast but incorrect there's always the "noacl" mount 
option.

-- 
Achim.

(on the road :-)

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

On Oct 26 17:03, Achim Gratz wrote:
> Am 26.10.2015 um 11:07 schrieb Corinna Vinschen:
> >Erm, really?  I tested this locally with a directory with hundreds
> >of files, each of which belonged to another user or group, and that
> >resulted in a 25% slowdown.  Not 1000%.  Oh boy.
> 
> That test is almost as bad as it can ever get.  Given that enumerating all
> AD accouts with mkpasswd takes about 2 hours and I'm doing something very
> similar here, I'm not even surprised.  I was more surprised to see the
> server go so fast, but my guess is that it can use jumbo frames to talk to
> the AD.

Ok, so you don't seem to think this is a major drawback.

> >>While that hurts, the more usual case with many files from the
> >>same user doesn't feel any slower at the moment.  The access through VPN
> >>will be interesting, though...
> >
> >Did you try this in the meantime?
> 
> No, sorry.

No worries.  I'm mulling over the idea to release 2.3.0 this week
without the new ACL handling code to get the latest fixes out of the
door first and push this stuff into a 2.4.0 release in November.

> >Given the above result, I'm wondering if we can afford using AuthZ at
> >all.  OTOH I don't see any other way to get the correct POSIX permissions
> >from a non-Cygwin ACL :(
> 
> If you really want fast but incorrect there's always the "noacl" mount
> option.

Right.  OTOH, maybe we could enhance the "acl" mount option?

"acl" -> "quickacl" -> "noacl"?


> -- 
> Achim.
> 
> (on the road :-)

https://www.youtube.com/watch?v=qRKNw477onU


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Achim Gratz]

Am 27.10.2015 um 10:27 schrieb Corinna Vinschen:
>> That test is almost as bad as it can ever get.  Given that enumerating all
>> AD accouts with mkpasswd takes about 2 hours and I'm doing something very
>> similar here, I'm not even surprised.  I was more surprised to see the
>> server go so fast, but my guess is that it can use jumbo frames to talk to
>> the AD.
>
> Ok, so you don't seem to think this is a major drawback.

I didn't say I would not like to see it run faster.  But considering the 
alternatives, working correctly all the times at the current speed seems 
to cover my more typical uses a lot better.

> No worries.  I'm mulling over the idea to release 2.3.0 this week
> without the new ACL handling code to get the latest fixes out of the
> door first and push this stuff into a 2.4.0 release in November.

As long as you keep reminding us which snapshot has the new ACL handling 
code, that is OK with me.  I will want to push out the snapshot in a 
week or two and remove some of my workarounds for ACL corrections and/or 
noacl mounted directories in order to see if these things are working 
now for real.

>>> Given the above result, I'm wondering if we can afford using AuthZ at
>>> all.  OTOH I don't see any other way to get the correct POSIX permissions
>> >from a non-Cygwin ACL :(
>>
>> If you really want fast but incorrect there's always the "noacl" mount
>> option.
>
> Right.  OTOH, maybe we could enhance the "acl" mount option?
>
> "acl" -> "quickacl" -> "noacl"?

Let's worry about that middle ground scenario when the ACL code has 
proven itself.  The danger here is that the edge cases that will make 
problems are not easy to spot before you run into them

-- 
Achim.

(on the road :-)


--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

On Oct 27 10:53, Achim Gratz wrote:
> Am 27.10.2015 um 10:27 schrieb Corinna Vinschen:
> >>That test is almost as bad as it can ever get.  Given that enumerating all
> >>AD accouts with mkpasswd takes about 2 hours and I'm doing something very
> >>similar here, I'm not even surprised.  I was more surprised to see the
> >>server go so fast, but my guess is that it can use jumbo frames to talk to
> >>the AD.
> >
> >Ok, so you don't seem to think this is a major drawback.
> 
> I didn't say I would not like to see it run faster.

Me neither.  No wonder Windows largely skips showing effective
permissions unless explicitely requested by the user.

> But considering the
> alternatives, working correctly all the times at the current speed seems to
> cover my more typical uses a lot better.

Ok.

> >No worries.  I'm mulling over the idea to release 2.3.0 this week
> >without the new ACL handling code to get the latest fixes out of the
> >door first and push this stuff into a 2.4.0 release in November.
> 
> As long as you keep reminding us which snapshot has the new ACL handling
> code, that is OK with me.

I guess you should better use the latest test releases, which I'll
always build with the new ACL handling.  The snapshots are rather for
quick&dirty testing the latest changes.

> I will want to push out the snapshot in a week or
> two and remove some of my workarounds for ACL corrections and/or noacl
> mounted directories in order to see if these things are working now for
> real.

Cool.  I'm looking forward to it.

> >>>Given the above result, I'm wondering if we can afford using AuthZ at
> >>>all.  OTOH I don't see any other way to get the correct POSIX permissions
> >>>from a non-Cygwin ACL :(
> >>
> >>If you really want fast but incorrect there's always the "noacl" mount
> >>option.
> >
> >Right.  OTOH, maybe we could enhance the "acl" mount option?
> >
> >"acl" -> "quickacl" -> "noacl"?
> 
> Let's worry about that middle ground scenario when the ACL code has proven
> itself.  The danger here is that the edge cases that will make problems are
> not easy to spot before you run into them

Good point.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Achim Gratz]

Achim Gratz writes:
> On my local laptop things look a bit different, a small ~5% subset of the
> test above goes from 20s to 200s and a different larger ~10% subset from 50s
> to 500s.  While that hurts, the more usual case with many files from the
> same user doesn't feel any slower at the moment.  The access through VPN
> will be interesting, though...

VPN access with the worst possible terrestrial roundtrip has been tested
for the same case now and goes from 52s to ~1700s or a factor of 33.  So
roundtrip delay adds an additional factor of about 3, but the server
response time seems to play the dominant role even in that scenario.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

On Dec  6 10:58, Achim Gratz wrote:
> Achim Gratz writes:
> > On my local laptop things look a bit different, a small ~5% subset of the
> > test above goes from 20s to 200s and a different larger ~10% subset from 50s
> > to 500s.  While that hurts, the more usual case with many files from the
> > same user doesn't feel any slower at the moment.  The access through VPN
> > will be interesting, though...
> 
> VPN access with the worst possible terrestrial roundtrip has been tested
> for the same case now and goes from 52s to ~1700s or a factor of 33.  So
> roundtrip delay adds an additional factor of about 3, but the server
> response time seems to play the dominant role even in that scenario.

Uhm... is that good or bad now?!?  Do you still think adding this
functionality is a good idea?


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Achim Gratz]

Corinna Vinschen writes:
>> VPN access with the worst possible terrestrial roundtrip has been tested
>> for the same case now and goes from 52s to ~1700s or a factor of 33.  So
>> roundtrip delay adds an additional factor of about 3, but the server
>> response time seems to play the dominant role even in that scenario.
>
> Uhm... is that good or bad now?!?  Do you still think adding this
> functionality is a good idea?

For most of the things I did it worked OK, so I still think AuthZ should
be used.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

On Dec  6 15:29, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> VPN access with the worst possible terrestrial roundtrip has been tested
> >> for the same case now and goes from 52s to ~1700s or a factor of 33.  So
> >> roundtrip delay adds an additional factor of about 3, but the server
> >> response time seems to play the dominant role even in that scenario.
> >
> > Uhm... is that good or bad now?!?  Do you still think adding this
> > functionality is a good idea?
> 
> For most of the things I did it worked OK, so I still think AuthZ should
> be used.

Ok, thanks a lot.  I'm just wondering if I should really push this to
stable state, given the fact that I won't be available starting next
week until 2016-01-06.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Achim Gratz]

Corinna Vinschen writes:
> Ok, thanks a lot.  I'm just wondering if I should really push this to
> stable state, given the fact that I won't be available starting next
> week until 2016-01-06.

Well, that looks like it might be a common schedule for other folks as
well, so you might just hold off until next year with the release.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Thomas Wolff]

On 23.10.2015 14:25, Corinna Vinschen wrote:
> On Oct 23 14:22, Corinna Vinschen wrote:
>> On Oct 23 11:06, Achim Gratz wrote:
>>> I don't have much time to test it right now (and won't have any time at all
>>> next week), but so far things look good.  The problem with the 0.2 test
>>> version with UID/GID mapping and not recognizing the primary domain in some
>>> cases is gone (might have been a fluke anyway).  Correlating the output from
>>> getfacl and icacls still requires some mental gymnastics, but I didn't find
>>> any obvious errors in the mode bits and ACL so far, which means that things
>>> like rsync (and some file tests) will now return the correct results for the
>>> cases I've looked at.
>> You won't believe how grateful I am having you testing this.  Thank you!
>>
>> Would you mind to read the comment at the start of sec_acl.cc?
> https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/sec_acl.cc;hb=a8ec1e804ee9ba2d6f8304731e593dcf167c9836#l27
>
>> I'd be
>> very interested in learning if the description is meaningful enough to
>> other developers.  I also fear we need to have an improved documentation
>> explaining how this works and what NOT to do, e.g., reorder ACLs :|
Sorry for the late response...
The description is mostly meaningful. Just the coexistence of X and 
X_OBJ entries isn't self-explanatory.
------
Thomas

--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2828 bytes --]

On Dec 21 14:22, Thomas Wolff wrote:
> On 23.10.2015 14:25, Corinna Vinschen wrote:
> >On Oct 23 14:22, Corinna Vinschen wrote:
> >>On Oct 23 11:06, Achim Gratz wrote:
> >>>I don't have much time to test it right now (and won't have any time at all
> >>>next week), but so far things look good.  The problem with the 0.2 test
> >>>version with UID/GID mapping and not recognizing the primary domain in some
> >>>cases is gone (might have been a fluke anyway).  Correlating the output from
> >>>getfacl and icacls still requires some mental gymnastics, but I didn't find
> >>>any obvious errors in the mode bits and ACL so far, which means that things
> >>>like rsync (and some file tests) will now return the correct results for the
> >>>cases I've looked at.
> >>You won't believe how grateful I am having you testing this.  Thank you!
> >>
> >>Would you mind to read the comment at the start of sec_acl.cc?
> >https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/sec_acl.cc;hb=a8ec1e804ee9ba2d6f8304731e593dcf167c9836#l27
> >
> >>I'd be
> >>very interested in learning if the description is meaningful enough to
> >>other developers.  I also fear we need to have an improved documentation
> >>explaining how this works and what NOT to do, e.g., reorder ACLs :|
> Sorry for the late response...
> The description is mostly meaningful. Just the coexistence of X and X_OBJ
> entries isn't self-explanatory.

I think I don't quite understand what you mean.  As the developer I'm
working under the assumption that the posix ACL description is known
(not wanting to explain this from scratch in the sources).

- USER_OBJ refers to the owner of the file.  Only one such entry
  exists and is equivalent to the POSIX permission bits for the owner.

- GROUP_OBJ refers to the owning group of the file.  Only one such
  entry exsist, same as for USER_OBJ.

- USER is an entry for a secondary user.  There can be an arbitrary
  number up to a system-defined maximum of them.  E.g, Peter is owner of
  the file, so he's the one refered to by the USER_OBJ entry.  Paul has
  an additonal entry in the ACL with, say, rw- perms.  Paul's permissions
  are given by a USER entry  "user:paul:rw-".

- GROUP is an entry for a secondary group.  Any number up to a system-defined
  maximum entries are possible.  E.g, the owner is Paul (USER_OBJ), the
  group is Users (GROUP_OBJ), there's an additional entry for the
  Administrators group giving them Full Access.  This one is a GROUP
  entry "group:Administrators:rwx".

Does this make it clearer?  Is there still something missing in the
source comment?


Thanks,
Corinna

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]