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 r
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 r
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 ha
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
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 u
> 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 w
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
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
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 whi
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 cygser
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 trie
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 VP
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
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 differen
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
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
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 re
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
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
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
20 matches
Mail list logo
