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=iq76sTbI3DuQmKudQXAzaP7rBOhxJlCCD3yMzwrB4I/+GhvriNWBb
	gwcwMeIpKqG0B6uY7DGhMdRZuZXfYnzrf9xVIScRfsNqGBXuntZcKKSBYT/75FLX
	GF/d8ZB3eQQvrfiEQJaRDB8/WKn/9DtdgRpnKfTsxhO+HiD2hP/fIA=
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=7EmEHv+AE0Yek4KBN0L6NZlhSHo=; b=SLvWRMOnCZL5DLIdpRQ1+ffc0DbD
	xcQd+OHeavlLGqL9D/6v3I0On7Hd3pqUqfKQNCI8ezEy+xiuZOR18yP7ZFIrXo/F
	sfJgBsVQNpNiMuQDfsrzjZLzww9VtBcS05XRuKqh1nUXIkb2h/Z1ouCK24DVgUnY
	okjO8VXRaKhKbLA=
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=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Fri, 20 Feb 2015 18:03:54 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.3
Message-ID:	<20150220170354.GE26084@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<announce DOT 20150218105937 DOT GA28211 AT calimero DOT vinschen DOT de> <87d255htw7 DOT fsf AT Rainer DOT invalid> <20150220095617 DOT GO26084 AT calimero DOT vinschen DOT de> <54E75BB9 DOT 90807 AT coverity DOT com> <20150220162442 DOT GA26084 AT calimero DOT vinschen DOT de> <54E763CD DOT 9000307 AT coverity DOT com>
MIME-Version:	1.0
In-Reply-To:	<54E763CD.9000307@coverity.com>
User-Agent:	Mutt/1.5.23 (2014-03-12)

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

On Feb 20 11:41, Tom Honermann wrote:
> On 02/20/2015 11:24 AM, Corinna Vinschen wrote:
> >On Feb 20 11:07, Tom Honermann wrote:
> >>On 02/20/2015 04:56 AM, Corinna Vinschen wrote:
> >>>>Lastly, running cygserver to cache the LDAP data has another side-eff=
ect
> >>>>when using VPN.  Since the cygserver is usually started before you've
> >>>>dialed into the VPN, your username and some groups will get reported =
as
> >>>>"DOM+User(12345)".  You have to restart cygserver after the VPN is up=
 to
> >>>>correct that.
> >>>
> >>>Yep.  We should contemplate to allow sending a signal to cygserver to
> >>>invalidate its cache.
> >>
> >>Perhaps cygserver could subscribe to network event notifications and
> >>automatically invalidate its cache?
> >>
> >>https://msdn.microsoft.com/en-us/library/windows/desktop/aa366334%28v=
=3Dvs.85%29.aspx
> >
> >How do you know if and when an interface change requires a cache
> >invalidation?
>=20
> I doubt there is a perfect algorithm, but perhaps a heuristic would work
> fairly well.  For non-mobile systems, interface changes are presumably
> rather rare and invalidation on the addition of any new interface might be
> acceptable.  For mobile systems migrating between networks, the situation=
 is
> tougher
> [...]

Maybe it is actually simpler than that.  Invalidating the cache as a
whole probably never makes sense.  In fact there are two reasons for
invalidation:

- The pw_name, pw_shell, pw_home, pw_gecos settings for a user changed.

- The interface to the DC was broken and there are entries of the type
  Achim mentioned, "DOM+User(RID)".

The first case can only be fixed by invalidating the cache on a regular
basis.  If we didn't fetch the info for a user for, say, 5 minutes, drop
the entry from the cache and renew the information by asking the DC
again.

As for the second case, the DOM+User(RID) entries are undesired and
wrong anyway.  So maybe the caching code could do what you said in the
first place.  Invalidate the cache on every network change.  But then,
only invalidate the entries of the aforementioned type.

Care to hack a bit?


Corinna

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

--9kBr9UDtZsI8nE8z
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJU52j6AAoJEPU2Bp2uRE+g5GsP/ib9e2dQqat950q37+dhevIx
15JRTntWO+ImNeYFWdQXscD74nScPjkxo0H8TStqnM8f9fW6eDp1PPnH431BPhjB
+YpI7nuwBEDKtODuoi2KDXQlbJ4vJZKaLN2I4rzvnfECt2Xox1QrCiw9dlv6vqiq
jxvh94VgKmkuMa0Z/jrmZZ8OQnxYBx1Rt33GjcMokUU5i8pZXnJvNZb8Dp9dSbFA
aO4WWGrwWRBmz5wokj7u2JDT5598a2mEN3OmcbeGCgMr3q2d+bO6IMP7PJPIJL80
GkcOxIivRb9xC0aHl1MbbLiAeauGR0xUxCzBeRriMRHeOhmtmW8Ag85uApkQa3YB
vEhTFXjVcRaaMlYcXJdDeQBLJ6dJZI8IWrO4cXD2dsd0qN6EQUPkgbgAJ9HcrAh/
Lbw5xWdRTni/9RqdsqldtYCYdHv12EStFGoVOlXM3iJtX+kn5XyzBhYze59D/Iho
jcZHyl4HwubqPqlO5U8RnDHNBV7l8ZpzAQCpW2V24wJsOvMi6sePj/G+GH3046ss
huZTD/z4dlCb3cDSgPiZmpy5N4v3YQdu63Kcr4Okdm1SdXQjo4IAVTvJ3cuC3wRH
vqti9N9PZ68eCP7U51XeqeTB41V1bELcYfJXd/IM4PTyy66mjfGyZidac4v9SQbV
AHZfcRZ+8qzM8fsrNIFT
=LCw2
-----END PGP SIGNATURE-----

--9kBr9UDtZsI8nE8z--

- Raw text -