X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=XSRTRD6kgvl0bB+h9EjcAbF208at9l+pO/U43J0vSZ+z7lpg5VtMT
	rFuVndkAFJxiRsJSBtw5WLLHDR0ojnjfInJBhoP5hefWvFpJfguajvg+kKVjpSeD
	20w7gUmzKlKX630CLvjvmn3vZPHuSAVPvk9Y4kdaZj1vcAvn2Bg410=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=c/12+zWUF106gO2NguNzbSgU+0I=; b=K06cQkMBhDwJrjyLfXViKcTUmnIa
	pdRbowczoySsTSq7Z+YU9kknGJ8zOolvVjZACZwnvEIKrFHCFlTUZepB/QfkDCi2
	17QfH2qPuJNE0NSpgn+2aaizpZmTpTlYXDxO4rX6q8v+J2xCznMKGMfw9PN/Sf1m
	ZjnELrAQiqGunkM=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPAM_BODY1 autolearn=no version=3.3.2
X-HELO: calimero.vinschen.de
Date: Tue, 14 Apr 2015 18:21:51 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Making Cygwin More Tolerant of Orphaned SIDs?
Message-ID: <20150414162151.GP7343@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CADi7v6LUZhr6UVSYA+Fe27f-aWJcxVxUXb3vR02rVuW9cG3a6A AT mail DOT gmail DOT com> <loom DOT 20150414T085644-392 AT post DOT gmane DOT org> <20150414080044 DOT GB7343 AT calimero DOT vinschen DOT de> <CADi7v6J=h7ydravvigVwMpT5P4QwMS1L73m1zhy==DtrL-SHhQ AT mail DOT gmail DOT com> <20150414092313 DOT GE7343 AT calimero DOT vinschen DOT de> <CADi7v6JVqPi9SE44CbfYfd-aWUd8w2=2Uu=2=BR6ZM6H9qDgqA AT mail DOT gmail DOT com> <20150414145323 DOT GH7343 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="FvF9dqTwB4R3n80B"
Content-Disposition: inline
In-Reply-To: <20150414145323.GH7343@calimero.vinschen.de>
User-Agent: Mutt/1.5.23 (2014-03-12)

--FvF9dqTwB4R3n80B
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr 14 16:53, Corinna Vinschen wrote:
> On Apr 14 07:24, Bryan Berns wrote:
> > On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen
> > >
> > > The problem is that Cygwin, or any other tool trying to resolve SIDs
> > > doesn't know a SID won't resolve before it tried.  And then it's an
> > > OS function which takes its time.  It's like checking for network
> > > machines providing shares.  Sometimes this test takes ages, but in
> > > this case, fortunately, you see that it takes ages in Explorer as
> > > well.
> > >
> > > As for ACLs, you can alleviate the problem somewhat by running cygser=
ver
> > > on the machine, which allows to cache SIDs for all processes.  So only
> > > the first process trying the SID will take time, followup processes w=
ill
> > > get the cached results from cygserver.
> > >
> > > Other than that, except for ignoring ACLs entirely (noacl) I have
> > > no idea how to solve this problem differently.
> >=20
> > Yes, I understand there's nothing Cygwin can do beforehand -- that
> > means sense.  I guess what I'm saying is that Cygwin doesn't appear to
> > be caching SIDs in certain scenarios.
> >=20
> > For example, I create a whole bunch of files (like 5000),  I use
> > icacls to append a new ACE.  Then I do a 'time ls -l
> > /cygdrive/c/somedir/*'.  Takes four seconds.  In the same Cygwin
> > session, I remove the local group (net localgroup testgroup /delete).
> >  I do the same 'time ls -l /cygdrive/c/somedir/*'.  Takes 20 seconds.
> > Subsequent runs in the also take 20 seconds.  Since I'm able to
> > continue to see the slowdown in the same session, cygserver wouldn't
> > help right?
> >=20
> > Is the above expected?
>=20
> Yes.  Without cygserver, caching only works from parent to child process.
> One run of ls can't cache data for a parallel run of ls in trhe same
> session.  As, btw., explained in the documentation:
>=20
>   https://cygwin.com/cygwin-ug-net/ntsec.html

...and if my reply wasn't clear enough:

Cygserver will help in this scenario as outlined in the documentation.
It caches the account information system-wide, so the stuff the first ls
cached is available for the next ls.  Or the next shell session.


Corinna

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

--FvF9dqTwB4R3n80B
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVLT6fAAoJEPU2Bp2uRE+gyxgP/RonFy77jNmJ64n1wDzupTzU
mUD3sdGFhaY+xmnAUrtbr6HFN/1lbfHmyxsa+I/ofnWEvCGv1VgRfYKG6F5Qs5Nm
RVSOdeOw67eSHAXSvu2lafZVUTRCxDK3Th9/hXcjTIS/hGoqPktUkmz2dYtg9yfl
z/0jYXwoh0VSOWSZY0lmq0Yd7bgnXQXBxNV/KQ6+vQuE3XP1goocfsQMYLeBbXRu
fD303ggG9uSJ7Ss9mC379CGtQGM+aTWUj4pjTUUEJ9vLaC1j+A2aIb5QcAEDf33Z
XiroxyWW9GEN3PgdU4cImXUnEPaqAaVapFNpVxLECLlSlCFX99Uv0l02T9RASln1
bbmWsHmn+YCqzLtuDdOvgJOleNTjWfAXQo10fZXSnnXc1XRo0UlgiirZK7bwI3cZ
hmDq6H3NxfCm5OzXaUEPXQTLwnoE7SoShtmDp9Euv6GFKDqTWgBFghEaKhaONveM
Ha+On+DmwUsvdrkiDp6eS52KJ/UFA3vPk1Y/icSgCVagx/KMczn+riyZddR9Ik4v
p9m96p2Ygcvr0O6S6bk5anBKq1UtEimN5coVLoQxXMbP5FeawWY+bwV2WNsfOx7V
aPDCpcCe15IPDkuUwnUWopxqAe2LQXaYMs07HHMQPfqKTv8wmr+tW159K0prFMch
WGDLI6wptl6Zgqvq7y20
=nKBD
-----END PGP SIGNATURE-----

--FvF9dqTwB4R3n80B--