[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.6

[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.6

[Corinna Vinschen]

Hi Cygwin friends and users,


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

This test release only fixes a really stupid bug I introduced
while trying to fix the pending signal problem reported in
https://cygwin.com/ml/cygwin/2015-09/msg00197.html

Nothing else changed compared to 2.3.0-0.5.


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:
-----------

- strftime(3) supports %s (seconds since Epoch) now.

- 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.

- Add support for Parallels Desktop FS (prlfs).


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

- Fix a potential SEGV on (at least) Wine.
  Addresses: https://cygwin.com/ml/cygwin/2015-10/msg00018.html

- Fix sigwait(3) to return errno instead of -1 and never to return with EINTR.

- Fix pthread_kill(3) to return errno instead of -1.

- Remove lingering pending signals after a thread exited.
  Addresses: https://cygwin.com/ml/cygwin/2015-09/msg00197.html

- Workaround a bug in Windows 10 NLS handling.
  Addresses: https://cygwin.com/ml/cygwin/2015-10/msg00547.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.6

[Achim Gratz]

Corinna Vinschen writes:
> I released a new TEST version of Cygwin, 2.3.0-0.6.
>
> This test release only fixes a really stupid bug I introduced
> while trying to fix the pending signal problem reported in
> https://cygwin.com/ml/cygwin/2015-09/msg00197.html

There are probably still some daemons in this code.  I've been trying
the test suite for perl-Test-SharedFork since this is one of the few
things that still fail (it's not been critical since it only affects
_testing_ of a single Perl distribution I use and this one is not in
Cygwin yet).

Up until the -0.5 test version the tests were mainly failing by
recognizing only one half of the fork (I don't know if it's the parent
or child one) as successful and hanging at the point where the child
should get reaped.  You could ^C your way back to the shell, but the
hanging processes could only be cleared by killing the process from the
windows side (/bin/kill -f).  If the child was killed, the parent
process actually continued from the hang.  That was racy in the sense
that once in a while those tests would actually succeed, especially when
run interactively and hang up at some mostly random point during the
test sequence.

With the new -06 version, things are more consistent:
both the child and the parent hang after the first test in the loop and
^C doesn't work at all.  Plus it already fails at t/01_simple instead of
at t/02_fork_method.


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

SD adaptation for Waldorf microQ V2.22R2:
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.6

[Achim Gratz]

Achim Gratz writes:
> With the new -06 version, things are more consistent:
> both the child and the parent hang after the first test in the loop and
> ^C doesn't work at all.  Plus it already fails at t/01_simple instead of
> at t/02_fork_method.

Just confirmed this on another system.  If I kill the child, then the
parent resumes and finishes the test loop alright and it can be
interrupted again from the shell.  The hang happens after the first test
succeeds in both the parent and child.


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.6

[Achim Gratz]

Achim Gratz writes:
> Just confirmed this on another system.  If I kill the child, then the
> parent resumes and finishes the test loop alright and it can be
> interrupted again from the shell.  The hang happens after the first test
> succeeds in both the parent and child.

I have just managed to kill the parent (returning the shell prompt) and
have the child complete the test loop output to the terminal.  So I
guess the communication ping-pong is somehow buggered up so that pipes
start blocking.


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

SD adaptation for Waldorf Blofeld V1.15B11:
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.6

[Corinna Vinschen]

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

On Nov  4 22:25, Achim Gratz wrote:
> Achim Gratz writes:
> > Just confirmed this on another system.  If I kill the child, then the
> > parent resumes and finishes the test loop alright and it can be
> > interrupted again from the shell.  The hang happens after the first test
> > succeeds in both the parent and child.
> 
> I have just managed to kill the parent (returning the shell prompt) and
> have the child complete the test loop output to the terminal.  So I
> guess the communication ping-pong is somehow buggered up so that pipes
> start blocking.

Staring into the latest version of my new function to remove pending
signals, after having some *more* coffee, it seems pretty clear I
screwed this up nicely.

What I was missing all the time was to iterate over the list of pending
signals if there's a pending signal which doesn't have to be cleared.
This case was just missing.  Duh!  I guess I didn't really cover myself
in glory here...

I applied yet another patch and uploaded a new developer snapshot
(this time *with* the ACL changes) to https://cygwin.com/snapshots/

Can you please give it a try ASAP?


Thank you,
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.6

[Corinna Vinschen]

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

On Nov  5 10:24, Corinna Vinschen wrote:
> On Nov  4 22:25, Achim Gratz wrote:
> > Achim Gratz writes:
> > > Just confirmed this on another system.  If I kill the child, then the
> > > parent resumes and finishes the test loop alright and it can be
> > > interrupted again from the shell.  The hang happens after the first test
> > > succeeds in both the parent and child.
> > 
> > I have just managed to kill the parent (returning the shell prompt) and
> > have the child complete the test loop output to the terminal.  So I
> > guess the communication ping-pong is somehow buggered up so that pipes
> > start blocking.
> 
> Staring into the latest version of my new function to remove pending
> signals, after having some *more* coffee, it seems pretty clear I
> screwed this up nicely.
> 
> What I was missing all the time was to iterate over the list of pending
> signals if there's a pending signal which doesn't have to be cleared.
> This case was just missing.  Duh!  I guess I didn't really cover myself
> in glory here...
> 
> I applied yet another patch and uploaded a new developer snapshot
> (this time *with* the ACL changes) to https://cygwin.com/snapshots/
> 
> Can you please give it a try ASAP?

For the records, I got a testcase from Achim to reproduce the issue
which, incidentally, is still present in that snapshot.  It turned out
that the problem Achim was reporting has nothing to do with the new code
clearing pending signals.  It was a completely different bug, which just
showed another behaviour due to the signal change.

In fact what happened was a deadlock when parent and child process
were industriously trying to lock a file using flock(2).  This must
have been present for a long time, in fact.

I (hopefully) fixed the issue and uploaded yet another developer
snapshot to https://cygwin.com/snapshots/ (with ACL changes again).

New test release follows soon.

Achim, thanks for the report and the testcase.


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.6

[Corinna Vinschen]

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

On Nov  5 18:55, Corinna Vinschen wrote:
> On Nov  5 10:24, Corinna Vinschen wrote:
> > On Nov  4 22:25, Achim Gratz wrote:
> > > Achim Gratz writes:
> > > > Just confirmed this on another system.  If I kill the child, then the
> > > > parent resumes and finishes the test loop alright and it can be
> > > > interrupted again from the shell.  The hang happens after the first test
> > > > succeeds in both the parent and child.
> > > 
> > > I have just managed to kill the parent (returning the shell prompt) and
> > > have the child complete the test loop output to the terminal.  So I
> > > guess the communication ping-pong is somehow buggered up so that pipes
> > > start blocking.
> > 
> > Staring into the latest version of my new function to remove pending
> > signals, after having some *more* coffee, it seems pretty clear I
> > screwed this up nicely.
> > 
> > What I was missing all the time was to iterate over the list of pending
> > signals if there's a pending signal which doesn't have to be cleared.
> > This case was just missing.  Duh!  I guess I didn't really cover myself
> > in glory here...
> > 
> > I applied yet another patch and uploaded a new developer snapshot
> > (this time *with* the ACL changes) to https://cygwin.com/snapshots/
> > 
> > Can you please give it a try ASAP?
> 
> For the records, I got a testcase from Achim to reproduce the issue
> which, incidentally, is still present in that snapshot.  It turned out
> that the problem Achim was reporting has nothing to do with the new code
> clearing pending signals.  It was a completely different bug, which just
> showed another behaviour due to the signal change.
> 
> In fact what happened was a deadlock when parent and child process
> were industriously trying to lock a file using flock(2).  This must
> have been present for a long time, in fact.
> 
> I (hopefully) fixed the issue and uploaded yet another developer
> snapshot to https://cygwin.com/snapshots/ (with ACL changes again).

Hang on for a while, I forgot to push the changes upstream before
creating the snapshot.  Try in half an hour or so.


Sorry,
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.6

[Achim Gratz]

Corinna Vinschen writes:
>> I (hopefully) fixed the issue and uploaded yet another developer
>> snapshot to https://cygwin.com/snapshots/ (with ACL changes again).
>
> Hang on for a while, I forgot to push the changes upstream before
> creating the snapshot.  Try in half an hour or so.

CYGWIN_NT-6.3-WOW Cygwin 2.3.0(0.291/5/3) 2015-11-05 18:01 i686 Cygwin
CYGWIN_NT-6.3 Cygwin 2.3.0(0.291/5/3) 2015-11-05 18:02 x86_64 Cygwin

These two snapshots fix the failures (which as you said had just moved
from semi-random to predictable with the changes in signal handling).
Thanks!


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
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.6

[Jan Bruun Andersen]

I am not sure if this DLL snapshot (cygwin1-20151105-dll) is supposed
to fix stuff like this, but I think I remember something about
ordering ACL's?

Anyway I have this 'bin' directory in my home which shows up with
'Administratörer' (Swedish for Administrators) as the owner. I had
hoped it would should me as the owner.

Some output:

jabba@Luap ~
$ ls -ld bin
drwxrwx---+ 1 Administratörer jabba 0 Oct 29 15:42 bin

jabba@Luap ~
$ getfacl bin
# file: bin
# owner: Administratörer
# group: jabba
user::rwx
group::rwx
group:SYSTEM:rwx
mask:rwx
other:---
default:user::rwx
default:group::rwx
default:group:SYSTEM:rwx
default:group:jabba:rwx
default:mask:rwx
default:other:---


jabba@Luap ~
$ icacls bin
bin NT instans\SYSTEM:(OI)(CI)(F)
    BUILTIN\Administrat▒rer:(OI)(CI)(F)
    LUAP\jabba:(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

This is on Windows 10 Pro x64.


On 5 November 2015 at 20:18, Achim Gratz <Stromeko@nexgo.de> wrote:
> Corinna Vinschen writes:
>>> I (hopefully) fixed the issue and uploaded yet another developer
>>> snapshot to https://cygwin.com/snapshots/ (with ACL changes again).
>>
>> Hang on for a while, I forgot to push the changes upstream before
>> creating the snapshot.  Try in half an hour or so.
>
> CYGWIN_NT-6.3-WOW Cygwin 2.3.0(0.291/5/3) 2015-11-05 18:01 i686 Cygwin
> CYGWIN_NT-6.3 Cygwin 2.3.0(0.291/5/3) 2015-11-05 18:02 x86_64 Cygwin
>
> These two snapshots fix the failures (which as you said had just moved
> from semi-random to predictable with the changes in signal handling).
> Thanks!
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> Factory and User Sound Singles for Waldorf Q+, Q and microQ:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
>
> --
> 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
>

--
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.6

[Corinna Vinschen]

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

On Nov  6 01:27, Jan Bruun Andersen wrote:
> I am not sure if this DLL snapshot (cygwin1-20151105-dll) is supposed
> to fix stuff like this, but I think I remember something about
> ordering ACL's?

It's explained in the announcement.

> Anyway I have this 'bin' directory in my home which shows up with
> 'Administratörer' (Swedish for Administrators) as the owner. I had
> hoped it would should me as the owner.

Well, that's not what the DLL is supposed to do.  The idea of the ACL
code is not to fake wrong ownership, it tries to evaluate POSIX ACLs as
correctly as possible given the underlying Windows ACL.

In your case the owner of the dir *is* the administrators group,
otherwise Cygwin wouldn't show that.  If you want to be owner you have
to make yourself actually owner, either in the Windows file security
tab, or by using Cygwin's chown as Admin.

> Some output:
> 
> jabba@Luap ~
> $ ls -ld bin
> drwxrwx---+ 1 Administratörer jabba 0 Oct 29 15:42 bin
> 
> jabba@Luap ~
> $ getfacl bin
> # file: bin
> # owner: Administratörer
> # group: jabba
> user::rwx
> group::rwx
> group:SYSTEM:rwx
> mask:rwx
> other:---
> default:user::rwx
> default:group::rwx
> default:group:SYSTEM:rwx
> default:group:jabba:rwx
> default:mask:rwx
> default:other:---
> 
> 
> jabba@Luap ~
> $ icacls bin
> bin NT instans\SYSTEM:(OI)(CI)(F)
>     BUILTIN\Administrat▒rer:(OI)(CI)(F)
>     LUAP\jabba:(OI)(CI)(F)

Note that the output of icacls does not tell you anything about
ownership.  The ACL does not contain this information.  For all we know
from this icacls output, the owner of the above ACL could be the "Guest"
user.


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.6

[Jan Bruun Andersen]

You were correct Corinna. It was indeed the administrators group that
was the owner. Windows security is perplexing to an old Unix-hand like
me. I guess something in the process of migrating and restoring my
home directory from another PC made the admin group the owner instead
of me. Luckily I have found this TAKEOWN utility which seems to fix
the issue.

On 6 November 2015 at 09:48, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> On Nov  6 01:27, Jan Bruun Andersen wrote:
>> I am not sure if this DLL snapshot (cygwin1-20151105-dll) is supposed
>> to fix stuff like this, but I think I remember something about
>> ordering ACL's?
>
> It's explained in the announcement.
>
>> Anyway I have this 'bin' directory in my home which shows up with
>> 'Administratörer' (Swedish for Administrators) as the owner. I had
>> hoped it would should me as the owner.
>
> Well, that's not what the DLL is supposed to do.  The idea of the ACL
> code is not to fake wrong ownership, it tries to evaluate POSIX ACLs as
> correctly as possible given the underlying Windows ACL.
>
> In your case the owner of the dir *is* the administrators group,
> otherwise Cygwin wouldn't show that.  If you want to be owner you have
> to make yourself actually owner, either in the Windows file security
> tab, or by using Cygwin's chown as Admin.
>
>> Some output:
>>
>> jabba@Luap ~
>> $ ls -ld bin
>> drwxrwx---+ 1 Administratörer jabba 0 Oct 29 15:42 bin
>>
>> jabba@Luap ~
>> $ getfacl bin
>> # file: bin
>> # owner: Administratörer
>> # group: jabba
>> user::rwx
>> group::rwx
>> group:SYSTEM:rwx
>> mask:rwx
>> other:---
>> default:user::rwx
>> default:group::rwx
>> default:group:SYSTEM:rwx
>> default:group:jabba:rwx
>> default:mask:rwx
>> default:other:---
>>
>>
>> jabba@Luap ~
>> $ icacls bin
>> bin NT instans\SYSTEM:(OI)(CI)(F)
>>     BUILTIN\Administrat▒rer:(OI)(CI)(F)
>>     LUAP\jabba:(OI)(CI)(F)
>
> Note that the output of icacls does not tell you anything about
> ownership.  The ACL does not contain this information.  For all we know
> from this icacls output, the owner of the above ACL could be the "Guest"
> user.
>
>
> 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