Levovo trackpoint come delayed (reproducable with xev)
Hi there, Lenovo trackpoint scrolling events get buffered somewhere until I release the button: then I get hundreds of scrolling events all at once. I can clearly see these events in xev. Result is that I don't really experience scrolling, rather jumping up and down with a random-like distance. With trackpoint I mean that red button in the middle of a Lenovo laptop. (Mouse wheel scrolling works perfect, in contrast.) Thanks regards, Paul -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
winsup/cygwin/release 1.7.10
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2012-01-22 17:57:52 Modified files: cygwin/release : 1.7.10 Log message: clarify wording Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/release/1.7.10.diff?cvsroot=uberbaumr1=1.5r2=1.6
winsup/cygwin ChangeLog fhandler.h fhandler_fi ...
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2012-01-22 21:43:25 Modified files: cygwin : ChangeLog fhandler.h fhandler_fifo.cc pipe.cc Log message: * fhandler.h (fhandler_fifo::arm): Declare new function. * fhandler_fifo.cc (fhandler_fifo::arm): Define new function. (fhandler_fifo::open): Fix handling of RDWR pipes to avoid opening a second handle. Use arm() function to set events. (fhandler_fifo::raw_read): Correctly go into connect again logic when we detect another writer is available. Use arm() function to set event. * pipe.cc (fhandler_pipe::create): Add more detail to debugging output. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5662r2=1.5663 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler.h.diff?cvsroot=uberbaumr1=1.451r2=1.452 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler_fifo.cc.diff?cvsroot=uberbaumr1=1.53r2=1.54 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/pipe.cc.diff?cvsroot=uberbaumr1=1.140r2=1.141
pure-ftpd access to cygdrive
Hello; How can I get access for cygdrive folder from pure-ftpd? If I browse I cant see that. Why? Thanks -- 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: cygport: broken vs. autotools by set -e
On Fri, 2012-01-20 at 14:50 +, Dave Korn wrote: Bash wasn't one of the packages updated - we've been on bash 4 since February last year, and I already had it installed last september when I was successfully using cygport to build the gcc-4.5.3-1 release. So I figure that the 4.x set -e behaviour might be part of this problem, but there must have been a change in cygport that's exposing it when it was previously hidden. I certainly can't think of one, and if cygport wasn't working with autotools I would have noticed a long time ago. :-) Is this occurring with one particular package, or with several, and which one(s)? Yaakov -- 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: YA call for snapshot testing
Hi, On 22/01/12 16:53, Christopher Faylor wrote: On Sun, Jan 22, 2012 at 12:47:19AM -0500, Christopher Faylor wrote: On Sun, Jan 22, 2012 at 01:07:45PM +1100, Shaddy Baddah wrote: Hi, On 22/01/12 05:18, Christopher Faylor wrote: Thanks for the positive feedback. It looks like if we can fix Yaakov's problem we may be ready to ship. I have one more problem to report. I tracked this problem as being introduced in the 2011-12-17 00:14:25 UTC snapshot, including the latest one, 2012-01-11 22:44:48 UTC: Sorry but you'll really need to provide more details about what your disk looks like so that we can attempt to duplicate the problem. Also, the stack trace that you provided doesn't look like it came from the 2012-01-11 snapshot. I can't tell for sure since you didn't provide cygcheck outpput. Also did this crash happen instantaneously or did it take a while? No problem. My initial report was light, I apologise. You are right about the stack trace, as it is from the first known bad snapshot, 2011-12-17. And it was wrong of me to use that snapshot, as the Bad address errors don't occur with the latest snapshot, 2012-01-11. The crash does not happen immediately, rather after some time, suggesting to me that find has done quite a number of traversals of the filesystem before it hits the problem. I've include output from this one, and attached a cygcheck.out this time: sbaddah@*** ~ $ uname -a CYGWIN_NT-6.1-WOW64 *** 1.7.10s(0.259/5/3) 20120111 22:39:26 i686 Cygwin sbaddah@*** ~ $ while :; do date; sleep 5; done find ~/.. -iname '*dokan*' -print [1] 8456 Sun Jan 22 21:23:40 AUSEDT 2012 /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Local/Microsoft/Windows/WER/ReportArchive/AppCrash_dokansshfs.exe_92876bc78a1f772de610a09c818961eff3f197_1d68964b /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Roaming/Dokan /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Roaming/Dokan/DokanSSHFS /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Roaming/Microsoft/Windows/Recent/dokan-sshfs-0.6.0(2).zip.lnk /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Roaming/Microsoft/Windows/Recent/dokan-sshfs-0.6.0.zip.lnk Sun Jan 22 21:23:45 AUSEDT 2012 Sun Jan 22 21:23:50 AUSEDT 2012 Sun Jan 22 21:23:55 AUSEDT 2012 0 [main] find 9496 C:\Users\Public\portapps\cygwin\bin\find.exe: *** fatal error - cmalloc would have returned NULL Stack trace: Frame Function Args 0028B378 6102F93B (0028B378, , , 0028C720) 0028B668 6102F93B (6119CD20, 8000, , 6119EB0F) 0028C698 61005E5C (6119E4A0, 0028C6C4, 0008, 61002C47) 0028C6B8 61005E98 (6119E4A0, 6119E498, 20010220, 6995FAFC) 0028C6F8 61003154 (6995FC6C, 0028C730, 20010220, 6102A422) 0028C7A8 610372A6 (6995FC14, 0030C000, , 0001) 0028C858 6104399C (6995FC14, 0020C000, , 75FFB9F2) 20010220 610E907B (2F632F65, 72657355, 62732F73, 61646461) End of stack trace Hangup sbaddah@**H ~ $ Sun Jan 22 21:24:00 AUSEDT 2012 And for completeness, here is the output of the same sequence from the last known good snapshot, that I found to be 20111216: sbaddah@*** ~ $ uname -a CYGWIN_NT-6.1-WOW64 *** 1.7.10s(0.255/5/3) 20111216 16:33:26 i686 Cygwin sbaddah@*** ~ $ while :; do date; sleep 5; done find ~/.. -iname '*dokan*' -print [1] 8276 Sun Jan 22 21:21:28 AUSEDT 2012 /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Local/Microsoft/Windows/WER/ReportArchive/AppCrash_dokansshfs.exe_92876bc78a1f772de610a09c818961eff3f197_1d68964b /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Roaming/Dokan /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Roaming/Dokan/DokanSSHFS /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Roaming/Microsoft/Windows/Recent/dokan-sshfs-0.6.0(2).zip.lnk /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Roaming/Microsoft/Windows/Recent/dokan-sshfs-0.6.0.zip.lnk Sun Jan 22 21:21:33 AUSEDT 2012 Sun Jan 22 21:21:39 AUSEDT 2012 Sun Jan 22 21:21:44 AUSEDT 2012 /cygdrive/c/Users/sbaddah/cygwin-home/../Downloads/dokan-sshfs-0.6.0(2).zip /cygdrive/c/Users/sbaddah/cygwin-home/../Downloads/dokan-sshfs-0.6.0.zip /cygdrive/c/Users/sbaddah/cygwin-home/../Downloads/DokanInstall_0.6.0.exe sbaddah@*** ~ $ Sun Jan 22 21:21:49 AUSEDT 2012 -- Hope that helps, Shaddy Cygwin Configuration Diagnostics Current System Time: Sun Jan 22 21:15:45 2012 Windows 7 Enterprise Ver 6.1 Build 7600 Running under WOW64 on AMD64 Path: C:\Users\Public\portapps\cygwin\usr\local\bin C:\Users\Public\portapps\cygwin\bin C:\Program Files (x86)\PC Connectivity Solution C:\Program Files\Common Files\Microsoft Shared\Windows Live C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Program Files (x86)\Enterprise Vault\EVClient C:\Program Files (x86)\Windows
Re: YA call for snapshot testing
Hi, On 22/01/12 21:33, Shaddy Baddah wrote: You are right about the stack trace, as it is from the first known bad snapshot, 2011-12-17. And it was wrong of me to use that snapshot, as the Bad address errors don't occur with the latest snapshot, 2012-01-11. It seems I spoke too soon. The behaviour under the latest snapshot is erratic. I thought it may be helpful to repeat the find, but without any -iname filter, just printing everything. The idea being to get an indication of whereabouts it is getting into trouble: sbaddah@*** ~ $ uname -a CYGWIN_NT-6.1-WOW64 *** 1.7.10s(0.259/5/3) 20120111 22:39:26 i686 Cygwin sbaddah@*** ~ $ find ~/.. -print sbaddah.20120111.lst 21 Looking through the end of the file, I saw a return of the Bad adddress errors: ... /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/afro-debian.vmem find: `/cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/afro-debian.vmem.lck': Bad address /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/afro-debian.vmem.lck /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/afro-debian.vmsd /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/afro-debian.vmss /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/afro-debian.vmx find: `/cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/afro-debian.vmx.lck': Bad address /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/afro-debian.vmx.lck /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/afro-debian.vmxf /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/vmware-0.log /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/vmware-1.log /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/vmware-2.log /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/vmware.log /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/afro-debian/vprintproxy.log find: `/cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/dsl': Bad address /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/dsl find: `/cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/free-ubuntu': Bad address /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/free-ubuntu find: `/cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/puppy': Bad address /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/puppy find: `/cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/slitaz': Bad address /cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/slitaz find: `/cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines/temp-w2k': Bad address 1 [main] find 14244 C:\Users\Public\portapps\cygwin\bin\find.exe: *** fatal error - cmalloc would have returned NULL Stack trace: Frame Function Args 0028A3C8 6102F93B (0028A3C8, , , ) 0028A6B8 6102F93B (6119CD20, 8000, , 6119EB0F) 0028B6E8 61005E5C (6119E4A0, 0028B714, 0006, 61002C47) 0028B708 61005E98 (6119E4A0, 6119E498, 0001, 0028C9E0) 0028C9B8 61003154 (, , 0028C9B4, 0028CAA8) 0028CBE8 610A828A (61267514, 0028CCC4, 0028CC48, 610816C0) 0028CC28 610A85DB (0003, 8000, , 6126A894) 0028CC48 610D34B5 (200384C0, 0001, 0001, 0003) 0028CC88 00401FD6 (002F, , 612682FC, 61006E38) 0028CD28 61006E38 (, 0028CD78, 61006430, ) End of stack trace Then a repeat of the same command as before also resulted in Bad address errors, but without a crash: sbaddah@*** ~ $ find ~/.. -iname '*dokan*' -print /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Local/Microsoft/Windows/WER/ReportArchive/AppCrash_dokansshfs.exe_92876bc78a1f772de610a09c818961eff3f197_1d68964b /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Roaming/Dokan /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Roaming/Dokan/DokanSSHFS /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Roaming/Microsoft/Windows/Recent/dokan-sshfs-0.6.0(2).zip.lnk /cygdrive/c/Users/sbaddah/cygwin-home/../AppData/Roaming/Microsoft/Windows/Recent/dokan-sshfs-0.6.0.zip.lnk find: `/cygdrive/c/Users/sbaddah/cygwin-home/../Documents/samsung/Kies/Podcast': Bad address find: `/cygdrive/c/Users/sbaddah/cygwin-home/../Documents/samsung/Kies/Ringtone': Bad address find: `/cygdrive/c/Users/sbaddah/cygwin-home/../Documents/samsung/Kies/Video': Bad address find: `/cygdrive/c/Users/sbaddah/cygwin-home/../Documents/SD16GB': Bad address find: `/cygdrive/c/Users/sbaddah/cygwin-home/../Documents/Virtual Machines': Bad address sbaddah@*** ~ $ For what it's worth, this gives an indication
Problem with gethostid
Hi all,
I have some problems with gethostid functions. When I run it on some
nodes of my cluster I get the same return value although hostnames and
IP addresses are different. Here are the logs for 2 nodes (test
program is in the attach, as well as cygcheck output).
C:\Users\gribov.y\\s-cw-head\pgas\a.exe
hostname = S-CW-NODE52
hostent:
h_name = S-CW-NODE52.XXX
address: 10.2.0.48
address: 192.168.80.1
address: 192.168.169.1
id = 364106303 15b3d23f
C:\Users\gribov.y\\s-cw-head\pgas\a.exe
hostname = S-CW-NODE53
hostent:
h_name = S-CW-NODE53.XXX
address: 10.2.0.56
address: 192.168.93.1
address: 192.168.244.1
id = 364106303 15b3d23f
Note that ids are equal although IP addresses are clearly different.
Some details:
1) I have replaced my domain name with XXX.
2) I run my program outside of Cygwin environment (i.e. not in bash);
not sure whether it's important
Has anyone seen this before? This may be due to some misconfig of my
cluster but I'm not sure what I should check.
--
Best regards,
Yuri
cygcheck.out
Description: Binary data
#include stdlib.h
#include stdio.h
#include netdb.h
int main(int argc, char **argv) {
char tmp[128];
struct in_addr **pptr;
FILE *hosts;
if( argc 1 (hosts = fopen(/etc/hosts, rb)) ) {
printf(/etc/hosts:\n);
while( !feof(hosts) ) {
fgets(tmp, sizeof(tmp), hosts);
printf(Next line: %s\n, tmp);
}
fclose(hosts);
}
gethostname(tmp, sizeof(tmp));
printf(hostname = %s\n, tmp);
struct hostent *e = gethostbyname(tmp);
printf(hostent:\n);
printf(h_name = %s\n, e-h_name);
for(pptr = (struct in_addr **)e-h_addr_list; *pptr; ++pptr) {
printf(address: %s\n, inet_ntoa(**pptr));
}
long id = gethostid();
printf(id = %u %x\n, (unsigned)gethostid(), (unsigned)gethostid());
return 0;
}
--
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: YA call for snapshot testing
On Sun, Jan 22, 2012 at 08:30:23AM +0100, marco atzeri wrote: On 1/22/2012 6:53 AM, Christopher Faylor wrote: On Sun, Jan 22, 2012 at 12:47:19AM -0500, Christopher Faylor wrote: On Sun, Jan 22, 2012 at 01:07:45PM +1100, Shaddy Baddah wrote: Hi, On 22/01/12 05:18, Christopher Faylor wrote: Thanks for the positive feedback. It looks like if we can fix Yaakov's problem we may be ready to ship. I have one more problem to report. I tracked this problem as being introduced in the 2011-12-17 00:14:25 UTC snapshot, including the latest one, 2012-01-11 22:44:48 UTC: Cgf I saw the problem in erratic way also before running updatedb. But it is very evanescent and usually linked on how find is called. Could you try the latest snapshot? cgf -- 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: 1.7.9 : date command fails for year 1900
cygwin sent the following at Friday, January 20, 2012 7:34 PM I'm seeing a problem with my setup where the date command fails in an odd way: this is what it does: $ date -d '1 January 1900' date: invalid date `1 January 1900' same thing on a linux box: $ date -d '1 January 1900' Mon Jan 1 00:00:00 PMT 1900 any dates after 1901 seem to work OK: $ date -d '1 January 1902' Wed Jan 1 00:00:00 PMT 1902 but nothing works before then: $ date -d 'today - 150 years' date: invalid date `today - 150 years' $ date -d 'today - 100 years' Sun Jan 21 01:33:27 WET 1912 this is the info for the date command: $ date --version date (GNU coreutils) 8.14 Packaged by Cygwin (8.14-1) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie. Where should I start debugging? Start by finding out exactly when date stops working. The followijng is the same date version, everything up to date, on Windws 7: /c date -d 1901-12-13\ 15:45:52 Fri, Dec 13, 1901 3:45:52 PM /c date -d 1901-12-13\ 15:45:51 date: invalid date `1901-12-13 15:45:51' /c date -d 1901-12-13\ 15:45:51.999 date: invalid date `1901-12-13 15:45:51.999' /c date -d 1901-12-13\ 15:45:52.000 Fri, Dec 13, 1901 3:45:52 PM So 1901-12-13 15:45:52 is the earliest that works Waiting a few minutes and repeating does not change this. When is that in seconds: /c date -d 1901-12-13\ 15:45:52 +%s -2147483648 %s give the number of seconds since 1970-01-01 00:00:00 UTC. So this critical time is 2147483648 seconds before the start of the Unix epoch. Now -2147483648 = -2^31. So it looks like cygwin date encodes seconds as signed long integers. Presumably, date on your linux box was compiled to use something bigger. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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: Putty and pre-shared keys with Cygwin's sshd
I believe that PuTTy is SSH2, while Cygwin is OpenSSH. You can convert them using ssh-keygen: ssh-keygen -f putty_key -i openssh_key -Len On Jan 22, 2012, at 1:47 AM, Andrew DeFaria wrote: On 01/21/2012 07:28 PM, Andrey Repin wrote: Well, *I* am using Cygwin SSH and PuTTY. And I've had no issues other than what I have explained. One way or another, back or forth, to my Linux box, or from it, from my Windows box to any imaginable server around the globe - no problem. The scenario here is going from one Windows box using PuTTY to another Windows box using OpenSSH in Cygwin. Using puttygen to create new keys, or converting keys from OpenSSH to PuTTY, or the other way around to use for Cygwin's ssh in test box. It just works. Exactly as described in PuTTY help file, chapter 8.2. I'm glad it's working for you, I wish it were working for me. You mention converting keys from OpenSSH to PuTTY, or the other way around. What is this conversion process that you speak of? How do you convert a PuTTY key to an OpenSSH key? Because so far nobody's mentioned where in this process I need to convert between the two. Check Windows event log. Though, it's obvious. Also keep an eye on nearby discussion regarding SSHD issues. It may be your case too. I will check when I get back into work (don't run Windows nor PuTTY at home to check things) but I thought Cygwin's sshd logs to /var/log/sshd.log. Otherwise why would I have a file there at all? -- Andrew DeFaria http://defaria.com Indecision is the key to flexibility. -- 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 -- 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: Putty and pre-shared keys with Cygwin's sshd
On 01/22/2012 10:21 AM, Len Giambrone wrote: I believe that PuTTy is SSH2, while Cygwin is OpenSSH. You can convert them using ssh-keygen: ssh-keygen -f putty_key -i openssh_key If this is true then it kinda kills the ease of use thing. It's hard enough trying to tell somebody to use puttygen then save keys, copy and paste them, etc. but now tell them Well log into a Cygwin server and run this command line 'cause the two systems talk different is not gonna go over well... I try to explain to people how getting Putty to do ssh, Reflection X to do X11, FireFTP or whatever to do ftp, ActiveState Perl to do Perl, etc. is the wrong way to go about putting together a good set of tools when you can more simply just get Cygwin to do all of those things and have all of those tools play nicely together. Here appears to be yet another example... -- Andrew DeFaria http://defaria.com If you talk to god, it's called religion. If god talks to you it's called insanity. -- 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: Putty and pre-shared keys with Cygwin's sshd
Greetings, Andrew DeFaria! You mention converting keys from OpenSSH to PuTTY, or the other way around. What is this conversion process that you speak of? How do you convert a PuTTY key to an OpenSSH key? Because so far nobody's mentioned where in this process I need to convert between the two. The PuTTY help file, chapter 8.2.12 Dealing with private keys in other formats. Check Windows event log. Though, it's obvious. Also keep an eye on nearby discussion regarding SSHD issues. It may be your case too. I will check when I get back into work (don't run Windows nor PuTTY at home to check things) but I thought Cygwin's sshd logs to /var/log/sshd.log. Otherwise why would I have a file there at all? I think it depends on service settings. But I prefer system event log, I have many ways to monitor it. -- WBR, Andrey Repin (anrdae...@freemail.ru) 22.01.2012, 22:34 Sorry for my terrible english... -- 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: YA call for snapshot testing
On 1/22/2012 5:57 PM, Christopher Faylor wrote: On Sun, Jan 22, 2012 at 08:30:23AM +0100, marco atzeri wrote: Cgf I saw the problem in erratic way also before running updatedb. But it is very evanescent and usually linked on how find is called. Could you try the latest snapshot? cgf le snapshots 20120122 07:28:45 seems to have solved the issue Regards Marco -- 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: YA call for snapshot testing
On Sun, Jan 22, 2012 at 08:11:18PM +0100, marco atzeri wrote: On 1/22/2012 5:57 PM, Christopher Faylor wrote: On Sun, Jan 22, 2012 at 08:30:23AM +0100, marco atzeri wrote: I saw the problem in erratic way also before running updatedb. But it is very evanescent and usually linked on how find is called. Could you try the latest snapshot? snapshots 20120122 07:28:45 seems to have solved the issue Looks like my guess was correct. I added refence counting to Cygwin's inaptly-named fhandler structures recently to work around a problem where a signal handler closed an fd while it was in the middle of a read. This caused the memory associated with an fd to be deleted only when the last thing referencing it was done with it. The very odd thing was that my implementation seemed to work right from the beginning. That has made me wonder what I got wrong. What I got wrong was the dup*() family of functions. If you dup a fd its reference counter was not reset so the memory associated with it was not deleted. Duh. Thanks for confirming. cgf -- 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: 1.7.9 : date command fails for year 1900
Thanks for corroborating my finding. Does anybody else think it is odd that this has not been pointed out before? Why would date use signed long integers to hold numbers of seconds? You would think this problem would have been detected in like 1974 or so. Do I just suck it up, or is there a work around for this? I am on 32bit winXP if it helps any. Incidentally cal seems to figure out dates in the distant past just fine: $ cal 14 10 1066 October 1066 Su Mo Tu We Th Fr Sa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Regards, -Dave On 1/22/2012 7:21 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote: cygwin sent the following at Friday, January 20, 2012 7:34 PM I'm seeing a problem with my setup where the date command fails in an odd way: this is what it does: $ date -d '1 January 1900' date: invalid date `1 January 1900' same thing on a linux box: $ date -d '1 January 1900' Mon Jan 1 00:00:00 PMT 1900 any dates after 1901 seem to work OK: $ date -d '1 January 1902' Wed Jan 1 00:00:00 PMT 1902 but nothing works before then: $ date -d 'today - 150 years' date: invalid date `today - 150 years' $ date -d 'today - 100 years' Sun Jan 21 01:33:27 WET 1912 this is the info for the date command: $ date --version date (GNU coreutils) 8.14 Packaged by Cygwin (8.14-1) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or laterhttp://gnu.org/licenses/gpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie. Where should I start debugging? Start by finding out exactly when date stops working. The followijng is the same date version, everything up to date, on Windws 7: /c date -d 1901-12-13\ 15:45:52 Fri, Dec 13, 1901 3:45:52 PM /c date -d 1901-12-13\ 15:45:51 date: invalid date `1901-12-13 15:45:51' /c date -d 1901-12-13\ 15:45:51.999 date: invalid date `1901-12-13 15:45:51.999' /c date -d 1901-12-13\ 15:45:52.000 Fri, Dec 13, 1901 3:45:52 PM So 1901-12-13 15:45:52 is the earliest that works Waiting a few minutes and repeating does not change this. When is that in seconds: /c date -d 1901-12-13\ 15:45:52 +%s -2147483648 %s give the number of seconds since 1970-01-01 00:00:00 UTC. So this critical time is 2147483648 seconds before the start of the Unix epoch. Now -2147483648 = -2^31. So it looks like cygwin date encodes seconds as signed long integers. Presumably, date on your linux box was compiled to use something bigger. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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: YA call for snapshot testing
Hi, On 23/01/12 06:33, Christopher Faylor wrote: On Sun, Jan 22, 2012 at 08:11:18PM +0100, marco atzeri wrote: On 1/22/2012 5:57 PM, Christopher Faylor wrote: On Sun, Jan 22, 2012 at 08:30:23AM +0100, marco atzeri wrote: I saw the problem in erratic way also before running updatedb. But it is very evanescent and usually linked on how find is called. Could you try the latest snapshot? snapshots 20120122 07:28:45 seems to have solved the issue Looks like my guess was correct. I added refence counting to Cygwin's inaptly-named fhandler structures recently to work around a problem where a signal handler closed an fd while it was in the middle of a read. This caused the memory associated with an fd to be deleted only when the last thing referencing it was done with it. The very odd thing was that my implementation seemed to work right from the beginning. That has made me wonder what I got wrong. What I got wrong was the dup*() family of functions. If you dup a fd its reference counter was not reset so the memory associated with it was not deleted. Duh. Thanks for confirming. Yes, I doubly confirm. All good now. Thanks for fixing this. Hopefully no more stoppers to a triumphant 1.7.10 release. And I can confirm a couple of other things. I encounter fewer fork/rebase issues with this release. And as per Corinna's call to test from a little while back, vboxsharedfolderfs still seems to work without any breakage. -- Thanks again, Shaddy -- 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: Putty and pre-shared keys with Cygwin's sshd
On 1/22/2012 10:21 AM, Len Giambrone wrote: I believe that PuTTy is SSH2, while Cygwin is OpenSSH. You can convert them using ssh-keygen: ssh-keygen -f putty_key -i openssh_key I tried this. It didn't work. Same error as before. Read 8.2.12 of the Putty help file - had no idea there was a format difference I had to do anything about! Tried what it said to do, use Conversions: Export to OpenSSH. But that key looks like: Ltsdo-adefaria:more /tmp/sshkey -BEGIN DSA PRIVATE KEY- MIIBuwIBAAKBgQDI+RkFLTib52+4+OzI+035r8fIConadaJuXNd+ZRSOvoLJar44 1m7jgSnp2A52LJ8LJeC99c7NQ1BBoHueRkgBWReH7orWH2T/vlFrPRgIU48vvgPH 4OrLFRtmN/uYj/BTbWFilN2jFZiiESSr4pSOPNNSblqj+UYXfFxc2ZrhIQIVANFm lV9qPmupo+/ZQqw1uTRypqve98yI2ZbXTuwIFLAps2T4rQKjmgmfghNWgmUEP0Sm V8qEfW8JvSh773fwYgtsAfos/+GPqc7V+UysKT2Na+5sOgqALSX6yfLBi0xAA2Iy ToRtrHupAoGAOS7f1yopMnELx7GhAtEtREN1zDikwa8dVhilM1M38+eZH4Z0Wd/3 H9W2iKKYjgj8lIIYGiXUxjEWhA3n/3N6HDT0O5X97Pp+dM7oHlAaKtGl0Y9ao+Zn SmXSquCsokL+1mh1baIe+VcyV2EA7Uat/B0zIlGpwfq4bQv0DmCjl4gCFDBh6pvn ckhR34s8s2jaQnkdgv+p -END DSA PRIVATE KEY- Whereas all of the lines of my ~/.ssh/authorized_keys files are single, lng lines. This doesn't look like it'll work... Tried it. It didn't work either. Can anybody give me clear, concise but complete end to end instructions on how to get this to work? -- Andrew DeFaria http://defaria.com Drive carefully. It's not only cars that can be recalled by their maker.% -- 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: 1.7.9 : date command fails for year 1900
cygwin sent the following at Sunday, January 22, 2012 3:39 PM Thanks for corroborating my finding. I wasn't corroborating. You originally asked for debugging help and I debugged it for you. Except that there was no bug. There was operator error. Does anybody else think it is odd that this has not been pointed out before? No. I think that it is odd that soemone is using date to print dates from over a century ago. Why would date use signed long integers to hold numbers of seconds? Because date actually is concerned with time and date. It needs to keep track of seconds; see the discussion of man date, below. Why long and not long long? Who really needs to set their clock to BC? You would think this problem would have been detected in like 1974 or so. Do I just suck it up, or is there a work around for this? Yes. Use a program intended to do what you wanted to do. The problem is not with date, but with how you tried to use it. The DESCRIPTION in man date says Display the current time in the given FORMAT, or set the system date. Since date is not intended to do date arithmatic (I'm guessing that that is what you are using it for), you shouldn't complain when it has limits. Date arithmaitic is an extra. If you want to do date arithmatic, use a program intended to do it. The one that I know of (this is not an endorsement) is dateplus, available in C and awk versions. But read the documentation, as it does not account for the switch between Julian to Gregorian calendars. And don't complain here if you have problems with it. http://www.orlandokuntao.com/mf_dateplus.html And remember that none of these track leap seconds. Incidentally cal seems to figure out dates in the distant past just fine: Not surprizing. They are different programs. And cal is tracking days, not seconds. /c cal 9 1752 September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Is this a bug? (Answer: It depends on where you are.) - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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
