delorie.com/archives/browse.cgi | search |
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--
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |