Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.3
Corinna Vinschen writes: On Feb 20 09:25, Achim Gratz wrote: Another thing I noticed is that pasting into an SSH connection often leaves the last few characters off and you need to hit another key to get them displayed. Not sure if this is related, but I seem to remember that this had been reported before and may be a regression. This should be fixed in CVS. In the pty function reading the input and doing all the canonical/non-canonical mode stuff, evaluating special characters etc, a condition was wrong which lead to keeping bytes in the buffer which should have been read. Excellent! How far are we from a release of 1.7.35? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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 1.7.35-0.3
On Feb 26 17:19, Achim Gratz wrote: Corinna Vinschen writes: On Feb 20 09:25, Achim Gratz wrote: Another thing I noticed is that pasting into an SSH connection often leaves the last few characters off and you need to hit another key to get them displayed. Not sure if this is related, but I seem to remember that this had been reported before and may be a regression. This should be fixed in CVS. In the pty function reading the input and doing all the canonical/non-canonical mode stuff, evaluating special characters etc, a condition was wrong which lead to keeping bytes in the buffer which should have been read. Excellent! How far are we from a release of 1.7.35? Days, IMHO. I have nothing imminent on my plate anymore. I'll create another, hopefully the last 1.7.35 test release today or tomorrow. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpl2QWSZDvlR.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 20 09:25, Achim Gratz wrote: Another thing I noticed is that pasting into an SSH connection often leaves the last few characters off and you need to hit another key to get them displayed. Not sure if this is related, but I seem to remember that this had been reported before and may be a regression. This should be fixed in CVS. In the pty function reading the input and doing all the canonical/non-canonical mode stuff, evaluating special characters etc, a condition was wrong which lead to keeping bytes in the buffer which should have been read. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpNoEw6ysJGx.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.3
On 2015-02-26 17:03, Corinna Vinschen wrote: On Feb 20 09:25, Achim Gratz wrote: Another thing I noticed is that pasting into an SSH connection often leaves the last few characters off and you need to hit another key to get them displayed. Not sure if this is related, but I seem to remember that this had been reported before and may be a regression. This should be fixed in CVS. In the pty function reading the input and doing all the canonical/non-canonical mode stuff, evaluating special characters etc, a condition was wrong which lead to keeping bytes in the buffer which should have been read. Perhaps this will also solve an issue that i still have not reported, namely under /usr/bin/script, i have to hit 4 times the Return key for the commandline to accept my command. The other characters no problem, only the Return key. My shell is tcsh under XP. The typescript file contains Control-M twice (followed by a regular \012), as expected. Regards, Denis Excoffier. -- 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 1.7.35-0.3
On Feb 21 12:25, cyg Simple wrote: From: Corinna Vinschen 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. How is pw_name going to change without a logoff? You're looking at the current user only. I'm talking about creating arbitrary passwd entries. - 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. Maybe too many requests to the DC for all users? Couldn't you just reinitialize if the network data changes? There are times when I would be on the DC and times when I am not with the same account. Doesn't matter, we're not invalidating the cache yet anyway. It was just idle musing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpufvgJLdhIM.pgp Description: PGP signature
RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.3
From: Corinna Vinschen 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. How is pw_name going to change without a logoff? - 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. Maybe too many requests to the DC for all users? Couldn't you just reinitialize if the network data changes? There are times when I would be on the DC and times when I am not with the same account. 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. A network change event works fine for me but not a timer event. Care to hack a bit? I'll take to NET plea as well. I'm doing good to read the list mail. -- cyg 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 1.7.35-0.3
Corinna Vinschen writes: And it's fast with other shells? Bash is reading/writing a history file, too, for instance... Yes, that's the puzzling bit; although I don't have nearly the same number of history lines in .bash_history, but the difference still is at least an order of magnitude. I can't debug this. Care to strace it to find out where the problem might be? Is that a 1.7.34+ problem? I think so. Since I switched very early to the LDAP integration code and have been running on snapshots most of the time since, I can't really say when exactly this was introduced. Hmm. On second thought, this might still be an LDAP problem. I have a hunch, and it's related to https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nfs https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-samba But we need to discuss and debug this. From me crummy little home network I have a hard time to see issues like that. Me too, I usually only see this when I'm on business travel, although I can use the VPN from home. One bug report at a time would be nice... This could be related to the changes in tty read/write related to https://cygwin.com/ml/cygwin-developers/2014-11/msg0.html but I have only 24h per day for hacking and debugging, too. Sans sleep, sorry. Understood. The timing seems about right, I first noticed this beginning of December. Yep. We should contemplate to allow sending a signal to cygserver to invalidate its cache. Somebody would have to code that. Sigh. Yes, yes. :-) In the meantime, restarting the service manually does work, unfortunately I can't add this to the script that opens the VPN tunnel. 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 1.7.35-0.3
On Feb 20 09:25, Achim Gratz wrote: Corinna Vinschen writes: This release introduces a revision of the LDAP calls done to fetch information from the DC. By limiting the search scope, the calls should now be faster even in bigger environments. Please give it a try with activated db settings for passwd and group entries in /etc/nsswitch.conf passwd: db group: db Please report back your experience, especially if you're suffering from slow startup problems. I'm still suffereing from slow startup problems over VPN, but I don't think it's the LDAP calls. As noted over in another thread the startup of tcsh takes a long time to start over a slow / long latency connection (the home directory is on a network share). And it's fast with other shells? Bash is reading/writing a history file, too, for instance... About half of that slowness is the history file load (saving the history on shutdown is also very slow), so either tcsh does something really stupid there or Cygwin does interact badly with how it tries to read/write these files. There is nothing happening network or CPU wise, so it feels very much like repeatedly hitting timeouts. I can't debug this. Care to strace it to find out where the problem might be? Is that a 1.7.34+ problem? Hmm. On second thought, this might still be an LDAP problem. I have a hunch, and it's related to https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nfs https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-samba But we need to discuss and debug this. From me crummy little home network I have a hard time to see issues like that. Another thing I noticed is that pasting into an SSH connection often leaves the last few characters off and you need to hit another key to get them displayed. Not sure if this is related, but I seem to remember that this had been reported before and may be a regression. One bug report at a time would be nice... This could be related to the changes in tty read/write related to https://cygwin.com/ml/cygwin-developers/2014-11/msg0.html but I have only 24h per day for hacking and debugging, too. Sans sleep, sorry. Lastly, running cygserver to cache the LDAP data has another side-effect 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. Somebody would have to code that. Sigh. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpGPo74BOau4.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.3
Corinna Vinschen writes: This release introduces a revision of the LDAP calls done to fetch information from the DC. By limiting the search scope, the calls should now be faster even in bigger environments. Please give it a try with activated db settings for passwd and group entries in /etc/nsswitch.conf passwd: db group: db Please report back your experience, especially if you're suffering from slow startup problems. I'm still suffereing from slow startup problems over VPN, but I don't think it's the LDAP calls. As noted over in another thread the startup of tcsh takes a long time to start over a slow / long latency connection (the home directory is on a network share). About half of that slowness is the history file load (saving the history on shutdown is also very slow), so either tcsh does something really stupid there or Cygwin does interact badly with how it tries to read/write these files. There is nothing happening network or CPU wise, so it feels very much like repeatedly hitting timeouts. Another thing I noticed is that pasting into an SSH connection often leaves the last few characters off and you need to hit another key to get them displayed. Not sure if this is related, but I seem to remember that this had been reported before and may be a regression. Lastly, running cygserver to cache the LDAP data has another side-effect 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. 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 1.7.35-0.3
On 02/20/2015 04:56 AM, Corinna Vinschen wrote: Lastly, running cygserver to cache the LDAP data has another side-effect 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=vs.85%29.aspx Somebody would have to code that. Sigh. There's just no getting around that, is there? How are those code writing AIs coming along anyway? Tom. -- 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 1.7.35-0.3
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-effect 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=vs.85%29.aspx How do you know if and when an interface change requires a cache invalidation? Somebody would have to code that. Sigh. There's just no getting around that, is there? How are those code writing AIs coming along anyway? Not at all. It looks like this project is dead upstream. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpPBSGHQWWnq.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 20 17:31, Marco Atzeri wrote: On 2/20/2015 5:07 PM, Tom Honermann wrote: Somebody would have to code that. Sigh. There's just no getting around that, is there? How are those code writing AIs coming along anyway? Tom. working in M$ at latest Windows version YMMD Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1V5hYXgjSu.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.3
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-effect 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=vs.85%29.aspx How do you know if and when an interface change requires a cache invalidation? 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 - invalidating the cache when not connected to a network from which it can be rebuilt would be frustrating. An ugly solution would be to invalidate depending on whether a (set of) user specified address(es) has transitioned from non-reachable to reachable (perhaps cache addresses of previously known AD servers?). A not-quite-as-ugly solution might be to invalidate based on specific networks (ie, a user specified wifi network name). None of these sound great to me, but perhaps would work well enough in practice. Tom. -- 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 1.7.35-0.3
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-effect 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=vs.85%29.aspx How do you know if and when an interface change requires a cache invalidation? 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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpy8hasBMOL5.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.3
On Feb 20 12:48, Achim Gratz wrote: Corinna Vinschen writes: And it's fast with other shells? Bash is reading/writing a history file, too, for instance... Yes, that's the puzzling bit; although I don't have nearly the same number of history lines in .bash_history, but the difference still is at least an order of magnitude. I can't debug this. Care to strace it to find out where the problem might be? Is that a 1.7.34+ problem? I think so. Since I switched very early to the LDAP integration code and have been running on snapshots most of the time since, I can't really say when exactly this was introduced. Hmm. On second thought, this might still be an LDAP problem. I have a hunch, and it's related to https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nfs https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-samba But we need to discuss and debug this. From me crummy little home network I have a hard time to see issues like that. Me too, I usually only see this when I'm on business travel, although I can use the VPN from home. Would be cool if you could test that. Assuming you're not accessing NFS shares, it may be the Samba stuff. The culprits are probably the calls to convert_samba_sd in check_file_access and the cygpsid::get_id method which explicitely checks for S-1-22 SIDs and tries to convert them to a Windows account per RFC 2307. If that's the problem, it might be prudent to switch this off by default and to enable that only via a setting in /etc/nsswitch.conf. One bug report at a time would be nice... This could be related to the changes in tty read/write related to https://cygwin.com/ml/cygwin-developers/2014-11/msg0.html but I have only 24h per day for hacking and debugging, too. Sans sleep, sorry. Understood. The timing seems about right, I first noticed this beginning of December. Yep. We should contemplate to allow sending a signal to cygserver to invalidate its cache. Somebody would have to code that. Sigh. Yes, yes. :-) In the meantime, restarting the service manually does work, unfortunately I can't add this to the script that opens the VPN tunnel. Erm... if you can't add *this* to the script, you wouldn't be able to add the kill -USR1 call to the script either, isn't it? Corinna P.S.: IRC? -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpA8p0O6KulB.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.3
Corinna Vinschen writes: Would be cool if you could test that. Assuming you're not accessing NFS shares, it may be the Samba stuff. The culprits are probably the calls to convert_samba_sd in check_file_access and the cygpsid::get_id method which explicitely checks for S-1-22 SIDs and tries to convert them to a Windows account per RFC 2307. All shares that I'm accessing are either NTFS (windows servers) or NetApp (most importantly, my homedir). Erm... if you can't add *this* to the script, you wouldn't be able to add the kill -USR1 call to the script either, isn't it? Sending a signal is still easier than restarting a service f you're not administrator. P.S.: IRC? Have to check if/how that works, but not today. 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 1.7.35-0.3
On Feb 20 17:48, Achim Gratz wrote: Corinna Vinschen writes: Would be cool if you could test that. Assuming you're not accessing NFS shares, it may be the Samba stuff. The culprits are probably the calls to convert_samba_sd in check_file_access and the cygpsid::get_id method which explicitely checks for S-1-22 SIDs and tries to convert them to a Windows account per RFC 2307. All shares that I'm accessing are either NTFS (windows servers) or NetApp (most importantly, my homedir). Hmm. In that case I'm stumped as to what may be the culprit here. Erm... if you can't add *this* to the script, you wouldn't be able to add the kill -USR1 call to the script either, isn't it? Sending a signal is still easier than restarting a service f you're not administrator. Good point. P.S.: IRC? Have to check if/how that works, but not today. Ok, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgperBjGusC87.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.3
On 2/20/2015 5:07 PM, Tom Honermann wrote: Somebody would have to code that. Sigh. There's just no getting around that, is there? How are those code writing AIs coming along anyway? Tom. working in M$ at latest Windows version -- 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 1.7.35-0.3
On 02/20/2015 12:03 PM, Corinna Vinschen wrote: 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. That all sounds very reasonable. Care to hack a bit? Oh, if only I could. If I had more time available, I'd have to go with more time to play with my kids (or sleep) :) Tom. -- 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 1.7.35-0.3
On Feb 20 13:51, Tom Honermann wrote: On 02/20/2015 12:03 PM, Corinna Vinschen wrote: 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. That all sounds very reasonable. Care to hack a bit? Oh, if only I could. If I had more time available, I'd have to go with more time to play with my kids (or sleep) :) Sleep is highly overrated. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpnc4zgrEm0k.pgp Description: PGP signature
