src/winsup/cygwin ChangeLog fhandler_socket.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-01-31 08:53:57 Modified files: winsup/cygwin : ChangeLog fhandler_socket.cc Log message: * fhandler_socket.cc (address_in_use): Improve comment readability. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5137r2=1.5138 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_socket.cc.diff?cvsroot=srcr1=1.265r2=1.266
src/winsup/cygwin ChangeLog syscalls.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-01-31 13:59:00 Modified files: winsup/cygwin : ChangeLog syscalls.cc Log message: * syscalls.cc (utmp_data): Fix potential buffer overflow. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5138r2=1.5139 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.572r2=1.573
[PATCH] Fix bogus fsync() error
If used on raw devices like /dev/sda fsync() always fails with EBADRQC (54) because FlushFileBuffers() always fails with ERROR_INVALID_FUNCTION (1). The attached patch fixes this by simply ignoring this error in the fhandler_base implementation. This should not affect any real flush errors which likely would return other error codes. An alternative approach would be to ignore the error only in a new fhandler_raw_dev/floppy::fsync(). IMO not worth the effort is this case. Christian 2011-01-31 Christian Franke fra...@computer.org * fhandler.cc (fhandler_base::fsync): Ignore ERROR_INVALID_FUNCTION error from FlushFileBuffers(). diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc index c97cc01..d7f46ec 100644 --- a/winsup/cygwin/fhandler.cc +++ b/winsup/cygwin/fhandler.cc @@ -1588,7 +1588,15 @@ fhandler_base::fsync () return 0; if (FlushFileBuffers (get_handle ())) return 0; - __seterrno (); + + /* Ignore ERROR_INVALID_FUNCTION because FlushFileBuffers() + always fails with this code on raw devices which are + unbuffered by default. */ + DWORD errcode = GetLastError(); + if (errcode == ERROR_INVALID_FUNCTION) +return 0; + + __seterrno_from_win_error (errcode); return -1; }
Re: 1.7.7: Bash interactive login takes very long ( 1 min)
Am 31.01.2011 10:17, schrieb Schulze, Martin: Hello, this is a fresh installation on a pc in a corporate domain environment. Cygwin has been installed for all users using a domain user account with local admin privileges. When I start cygwin.bat (wether as privileged user or as normal user, that doesn't matter), it takes always more than 60 seconds before the prompt appears. How can I trace what the problem is? The first thing to do is to deinstall bash-completion and retry. -- Matthias Andree -- 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.7: Bash interactive login takes very long ( 1 min)
Am 31.01.2011 10:41, schrieb martin.schu...@gmx.de: Hello, this is a fresh installation on a pc in a corporate domain environment. Cygwin has been installed for all users using a domain user account with local admin privileges. ... can you please stop reposting over and over again? Thank you. -- Matthias Andree -- 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.7: Bash interactive login takes very long ( 1 min)
Le 31/01/2011 10:41, martin.schu...@gmx.de a écrit : Hello, this is a fresh installation on a pc in a corporate domain environment. Cygwin has been installed for all users using a domain user account with local admin privileges. When I start cygwin.bat (wether as privileged user or as normal user, that doesn't matter), it takes always more than 60 seconds before the prompt appears. How can I trace what the problem is? as usual, do you have bash-completion, if yes, get rid of it and try again. Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net -- 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] Updated: OpenSSH-5.7p1-1
On Jan 30 21:13, totaltransaction wrote: Corinna Vinschen wrote: I've just updated the Cygwin version of OpenSSH to 5.7p1-1. Routine create_host_keys of script ssh-host-config has not been modified to create ECDSA host key files. Perhaps this is intentional, during an intro period? No, I just didn't change the script. Thanks for the reminder. I'll fix that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: On write command
On 31/01/2011 01:52, Larry Hall (Cygwin) wrote:
On 1/29/2011 8:20 AM, Angelo Graziosi wrote:
I would ask if on Cygwin I can use the 'write' command:
write - send a message to another user
$ write USER [ttyname]
I remember I have used it some years ago, but not remember if it was on
GNU/Linux or Cygwin.
I did a research on http://cygwin.com/packages and didn't find it, but
perhaps I did the wrong search..
No, that's the correct place to search. If it's not showing up, none of
the current packages provide 'write'.
It's part of util-linux, but it's configured out of the build on Cygwin,
because it relies on a working utmp file to operate. Which we don't have.
Hmm, I'm in the middle of a gcc testrun right now and can't rebuild my DLL,
but I noticed a few interesting points about the code:
winsup/cygwin/include/utmpx.h
/* Must be kept in sync with struct utmp as defined in sys/utmp.h! */
struct utmpx
{
shortut_type;
pid_tut_pid;
char ut_line[UT_LINESIZE];
char ut_id[UT_IDLEN];
time_t ut_time;
char ut_user[UT_NAMESIZE];
char ut_host[UT_HOSTSIZE];
long ut_addr;
struct timeval ut_tv;
};
winsup/cygwin/include/sys/utmp.h
struct utmp
{
shortut_type;
pid_tut_pid;
char ut_line[UT_LINESIZE];
char ut_id[UT_IDLEN];
time_t ut_time;
char ut_user[UT_NAMESIZE];
char ut_host[UT_HOSTSIZE];
long ut_addr;
};
That could explain why successive calls to getutent() appear to lose frame
across the contents of utmp. Also,
winsup/cygwin/syscalls.cc
/* Note: do not make NO_COPY */
static struct utmp utmp_data_buf[16];
static unsigned utix = 0;
#define nutdbuf (sizeof (utmp_data_buf) / sizeof (utmp_data_buf[0]))
#define utmp_data ({ \
if (utix nutdbuf) \
utix = 0; \
utmp_data_buf + utix++; \
})
I haven't slept all night, but isn't that going to overrun by one? Anyway
with the fix to utmp.h to add ut_tv (and a #include sys/time.h), write.exe
compiles and works...
cheers,
DaveK
--
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: On write command
On Jan 31 11:54, Dave Korn wrote:
On 31/01/2011 01:52, Larry Hall (Cygwin) wrote:
No, that's the correct place to search. If it's not showing up, none of
the current packages provide 'write'.
It's part of util-linux, but it's configured out of the build on Cygwin,
because it relies on a working utmp file to operate. Which we don't have.
Hmm, I'm in the middle of a gcc testrun right now and can't rebuild my DLL,
but I noticed a few interesting points about the code:
winsup/cygwin/include/utmpx.h
/* Must be kept in sync with struct utmp as defined in sys/utmp.h! */
struct utmpx
{
short ut_type;
pid_t ut_pid;
char ut_line[UT_LINESIZE];
char ut_id[UT_IDLEN];
time_t ut_time;
char ut_user[UT_NAMESIZE];
char ut_host[UT_HOSTSIZE];
long ut_addr;
struct timeval ut_tv;
};
winsup/cygwin/include/sys/utmp.h
struct utmp
{
short ut_type;
pid_t ut_pid;
char ut_line[UT_LINESIZE];
char ut_id[UT_IDLEN];
time_t ut_time;
char ut_user[UT_NAMESIZE];
char ut_host[UT_HOSTSIZE];
long ut_addr;
};
That could explain why successive calls to getutent() appear to lose frame
across the contents of utmp. Also,
winsup/cygwin/syscalls.cc
/* Note: do not make NO_COPY */
static struct utmp utmp_data_buf[16];
static unsigned utix = 0;
#define nutdbuf (sizeof (utmp_data_buf) / sizeof (utmp_data_buf[0]))
#define utmp_data ({ \
if (utix nutdbuf) \
utix = 0; \
utmp_data_buf + utix++; \
})
I haven't slept all night, but isn't that going to overrun by one? Anyway
with the fix to utmp.h to add ut_tv (and a #include sys/time.h), write.exe
compiles and works...
The utmp file is in the old utmp format for backward compatibility. The
utx functions are available and return a ut_tv field, but it's just
extracted from the utmp ut_time field at function call time. The right
thing to do for write is to have a autoconf test for the ut_tv field
and not using it, if it's not available.
In theory we should switch to a utmpx file at one point. When we do
this, we can also add the ut_addr_v6 field, which is missing so far.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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: On write command
On 31/01/2011 11:49, Corinna Vinschen wrote: The utmp file is in the old utmp format for backward compatibility. The utx functions are available and return a ut_tv field, but it's just extracted from the utmp ut_time field at function call time. The right thing to do for write is to have a autoconf test for the ut_tv field and not using it, if it's not available. Nah, I was mistaken. It actually works fine as-is. I was fooled by the way old utmp entries get the first char of the username NULled out into thinking it was getting bad data, but a quick login convinced me that write actually works just fine and all the util-linux maintainer needs do is add the configure option to enable building it. I still think that utmp_data macro is going to return utmp_data_buf[nutdbuf] at some point, though. Shouldn't it be if (utix = nutdbuf)? cheers, DaveK -- 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: On write command
On Jan 31 13:28, Dave Korn wrote: I still think that utmp_data macro is going to return utmp_data_buf[nutdbuf] at some point, though. Shouldn't it be if (utix = nutdbuf)? Indeed. Thanks for catching. I fixed it in CVS. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: After installing 1.7.7 command ls is null --now with cygcheck.out
On 2011-01-31 15:15Z, Jørgen Steensgaard wrote: I have just installed 1.7.7 after several unsuccessful attempts. Several auxiliary libraries were not included in the installation after setup finished. OK -- so I had to locate and rerun setup repeatedly. cygcheck output indicates version 1.7.5, not 1.7.7: 2547k 2010/04/12 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2010/4/12 19:07 Cygwin DLL version info: DLL version: 1.7.5 Are you using the current 'setup.exe'? Have you ruled out BLODA? http://cygwin.com/faq/faq.using.html#faq.using.bloda -- 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: After installing 1.7.7 command ls is null --now with cygcheck.out
On 01/31/2011 10:15 AM, Jørgen Steensgaard wrote: Hi I have just installed 1.7.7 after several unsuccessful attempts. Several auxiliary libraries were not included in the installation after setup finished. OK -- so I had to locate and rerun setup repeatedly. At some point I succeeded in having a terminal running with a bash-shell. It was probably my own fault not to have 'find' and 'sed' included, since that obviously is supposed to be common knowledge. Finally with the terminal running the shell -- including, finally, usual command editing facilities -- one problem remains ls gives me no reaction at all :-( I can type other commands and get the expected behaviour, but not ls -- and who knows what others. Quite an experience! With patience I might become as pleased with 1.7 as with a 1.5 on another machine. Any suggestions? I include a cygcheck.out, the generation of which followed the message: garbled output from 'id' command - no uid= found Sincerely Jørgen Steensgaard I'm having this exact same problem. And in my cygcheck Cygwin DLL is reporting as 1.7.5. Regards, Gerry -- 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: Issue with socket SO_REUSEADDR when a client is connected.
The Cygwin workaround to fix the WinSock SO_REUSEADDR behaviour from back in 2006 was not so nifty after all. I just fixed that in CVS. I'm going to generate a new developer snapshot right now. Should be up in a couple of minutes. Using cygwin snapshot, the testcase and varnishtest program works fine. This bugfix will be included in cygwin 1.7.8 ? There is any estimated release date for cygwin 1.7.8? -- 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: 16-bit wchar_t on Windows and Cygwin
[adding cygwin and coreutils for a wc issue] On 01/30/2011 07:04 PM, Bruno Haible wrote: Hi, It is known for a long time that on native Windows, the wchar_t[] encoding on strings is UTF-16. [1] Now, Corinna Vinschen has confirmed that it is the same for Cygwin = 1.7. [2] POSIX requires that 1 wchar_t corresponds to 1 character; so any use of surrogates to get the full benefit of UTF-16 falls outside the bounds of POSIX. At which point, the POSIX definition of those functions no longer apply, and we can (try) to make the various wc* functions try to behave as smartly as possible (as is the case with Cygwin); where those smarts are only needed when you use surrogate pairs. If cygwin's approach is correct, then maybe the thing to do is codify those smarts for all implementations with 16-bit wchar_t as an extension to POSIX that all gnulib clients can rely on, and thus minimize the #ifdefs in such clients. What consequences does this have? 1) All code that uses the functions from wctype.h (wide character classification and mapping) or wcwidth() malfunctions on strings that contains Unicode characters outside the BMP, i.e. outside the range U+..U+. Not necessarily. Such code falls outside of POSIX, but it may still be a well-behaved extension if given sane behavior for how to deal with surrogates. 2) Code that uses mbrtowc() or wcrtomb() is also likely to malfunction. On Cygwin = 1.7 mbrtowc() and wcrtomb() is implemented in an intelligent but somewhat surprising way: wcrtomb() may return 0, that is, produce no output bytes when it consumes a wchar_t. Now with a chinese character outside the BMP: $ 1 4 $ printf 'a \xf0\xa1\x88\xb4 b\n' | wc -w -m 3 6 On Cygwin 1.7.5 (with LANG=C.UTF-8 and 'wc' from GNU coreutils 8.5): $ printf 'a\xf0\xa1\x88\xb4b\n' | wc -w -m 1 5 $ printf 'a \xf0\xa1\x88\xb4 b\n' | wc -w -m 2 7 So both the number of characters and the number of words are counted wrong as soon as non-BMP characters occur. Does this represent a bug in cygwin's mbrtowc routines that could be fixed by cygwin? Or, does this represent a bug in coreutils for using mbrtowc one character at a time instead of something like mbsrtowcs to do bulk conversions? And if we decide that cygwin's extensions are sane, how much harder is it to characterize what a program must do to be portable to both 16-bit and 32-bit wchar_t if they are guaranteed the same behavior for all hosts of the same-size wchar_t? In other words, would it really require that many #ifdefs in coreutils to portably and simultaneously support both sizes of wchar_t? I'm more in favour of overriding wchar_t and all functions that depend on it - like we did successfully for the socket functions. In practice, this would mean that on Windows (both native Windows and Cygwin = 1.7) the use of a 'wchar_t' module will - override wchar_t to be 32 bits, like in glibc, - cause functions from mbrtowc() to wcwidth() to be overridden. Since the corresponding system functions are unusable, the replacements will use the modules from libunistring (such as unictype/ctype-alnum and uniwidth/width). That's a lot of overriding, for anything that uses wchar_t in its API, and throws out a lot of what cygwin already provides. It also means that compiler primitives, like Lxyz, which result in 16-bit wchar_t arrays, will be unusable with your 32-bit wchar_t override. In other words, I don't think it's a good idea to be doing that. C1x will be adding compiler support for mandatory char16_t and char32_t types for UTF-16 and UTF-32 data, independently of whether wchar_t is 16-bit or 32-bit; maybe the better thing is to proactively start providing the new interfaces in uchar.h that will result from C1x adoption (and convert GNU programs to use this rather than wchar_t for character operations), although without compiler support for u and U (and even u8), we are no better than ditching compiler support for L if you force a wchar_t size override. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1516.pdf lists: 7.27 Unicode utilities uchar.h 1 The header uchar.h declares types and functions for manipulating Unicode characters. 2 The types declared are mbstate_t (described in 7.29.1) and size_t (described in 7.19); char16_t which is an unsigned integer type used for 16-bit characters and is the same type as uint_least16_t (described in 7.20.1.2); and char32_t which is an unsigned integer type used for 32-bit characters and is the same type as uint_least32_t (also described in 7.20.1.2). mbrtoc16 c16rtomb mbrtoc32 c32rtomb but no variants for replacing wprintf and friends (convert to multibyte and use printf and friends instead). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Issue with socket SO_REUSEADDR when a client is connected.
On 1/31/2011 11:12 AM, jdzstz - gmail dot com wrote: The Cygwin workaround to fix the WinSock SO_REUSEADDR behaviour from back in 2006 was not so nifty after all. I just fixed that in CVS. I'm going to generate a new developer snapshot right now. Should be up in a couple of minutes. Using cygwin snapshot, the testcase and varnishtest program works fine. This bugfix will be included in cygwin 1.7.8 ? Snapshots are the basis for the coming release so yes. There is any estimated release date for cygwin 1.7.8? Yes. ...Oh, you wanted to know what that estimate is? ;-) Currently the thought is sometime in early February. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: 16-bit wchar_t on Windows and Cygwin
On Jan 31 09:58, Eric Blake wrote: 2) Code that uses mbrtowc() or wcrtomb() is also likely to malfunction. On Cygwin = 1.7 mbrtowc() and wcrtomb() is implemented in an intelligent but somewhat surprising way: wcrtomb() may return 0, that is, produce no output bytes when it consumes a wchar_t. Now with a chinese character outside the BMP: $ 1 4 $ printf 'a \xf0\xa1\x88\xb4 b\n' | wc -w -m 3 6 On Cygwin 1.7.5 (with LANG=C.UTF-8 and 'wc' from GNU coreutils 8.5): $ printf 'a\xf0\xa1\x88\xb4b\n' | wc -w -m 1 5 $ printf 'a \xf0\xa1\x88\xb4 b\n' | wc -w -m 2 7 So both the number of characters and the number of words are counted wrong as soon as non-BMP characters occur. Does this represent a bug in cygwin's mbrtowc routines that could be fixed by cygwin? Or, does this represent a bug in coreutils for using mbrtowc one character at a time instead of something like mbsrtowcs to do bulk conversions? Just to clarify a bit. This has been discussed on the cygwin-developer mailing list back in 2009. The original code which handled UTF-16 surrogates always wrote at least 1 byte to the destination UTF-8 string. However, the problem is that Windows filenames may contain lone surrogate pairs, even though the filename is usually interpreted as UTF-16. So the current code returns 0 bytes for the first surrogate half and only writes the full UTF-8 sequence after the second surrogate half has been evaluated. In the case where a lone high surrogate is still pending, but the low surrogate is missing, we can just write out the high surrogate in CESU-8 encoding. This would not have been possible if we had already written the first byte of the UTF-8 string. Lone low surrogates are written as CESU-8 sequence immediately so they are nothing to worry about. As for wctomb/wcrtomb returning 0: Even if this looks like kind of a stretch, this should not be a problem per POSIX. A return value of 0 from wctomb/wcrtomb has no special meaning(*). Even in the case where the incoming wide char is L'\0', the resulting \0 is written and 1 is returned. Since 0 bytes have been written to the destination string, returning 0 is perfectly valid. If a calling function misinterprets the return value of 0 as an error or EOF, it's not a bug in wctomb/wcrtomb. For the original discussion, see http://cygwin.com/ml/cygwin-developers/2009-09/msg00065.html Corinna (*) http://pubs.opengroup.org/onlinepubs/9699919799/functions/wcrtomb.html -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: After installing 1.7.7 command ls is null --now with cygcheck.out
In my case, I installed cygwin a few months ago and yesterday I went to upgrade it and install several packages. As it was going along it said that cygwin1.dll was busy so I pressed Continue and at the end it said a reboot was required. And so I rebooted the machine. When I logged back in, cygwin was not behaving correctly. ls, find, cat, cp, maybe more commands were not functioning correctly. The was after upgrading to 1.7.7. When I check cygcheck output it shows cygwin1.dll as 1.7.5. If I try and run strace, it fails with an error about a missing symbol. There were also a number of errors showing for postinstall scripts. Where in this process did either I or the install go wrong? Regards, Gerry -- 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: After installing 1.7.7 command ls is null --now with cygcheck.out
On 01/31/2011 01:55 PM, Gerry Reno wrote: In my case, I installed cygwin a few months ago and yesterday I went to upgrade it and install several packages. As it was going along it said that cygwin1.dll was busy so I pressed Continue and at the end it said a reboot was required. And so I rebooted the machine. When I logged back in, cygwin was not behaving correctly. ls, find, cat, cp, maybe more commands were not functioning correctly. The was after upgrading to 1.7.7. When I check cygcheck output it shows cygwin1.dll as 1.7.5. If I try and run strace, it fails with an error about a missing symbol. There were also a number of errors showing for postinstall scripts. Where in this process did either I or the install go wrong? Regards, Gerry Also, we have cygrunsrv operating services if that could have any bearing on this. Regards, Gerry -- 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: After installing 1.7.7 command ls is null --now with cygcheck.out
On 1/31/2011 2:16 PM, Gerry Reno wrote: On 01/31/2011 01:55 PM, Gerry Reno wrote: In my case, I installed cygwin a few months ago and yesterday I went to upgrade it and install several packages. As it was going along it said that cygwin1.dll was busy so I pressed Continue and at the end it said a reboot was required. And so I rebooted the machine. When I logged back in, cygwin was not behaving correctly. ls, find, cat, cp, maybe more commands were not functioning correctly. The was after upgrading to 1.7.7. When I check cygcheck output it shows cygwin1.dll as 1.7.5. If I try and run strace, it fails with an error about a missing symbol. There were also a number of errors showing for postinstall scripts. Where in this process did either I or the install go wrong? Also, we have cygrunsrv operating services if that could have any bearing on this. This is why you got the complaint about cygwin1.dll being busy. When you did the upgrade, did you download the current 'setup.exe' from cygwin.com? -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: After installing 1.7.7 command ls is null --now with cygcheck.out
On 01/31/2011 03:00 PM, Larry Hall (Cygwin) wrote: On 1/31/2011 2:16 PM, Gerry Reno wrote: On 01/31/2011 01:55 PM, Gerry Reno wrote: In my case, I installed cygwin a few months ago and yesterday I went to upgrade it and install several packages. As it was going along it said that cygwin1.dll was busy so I pressed Continue and at the end it said a reboot was required. And so I rebooted the machine. When I logged back in, cygwin was not behaving correctly. ls, find, cat, cp, maybe more commands were not functioning correctly. The was after upgrading to 1.7.7. When I check cygcheck output it shows cygwin1.dll as 1.7.5. If I try and run strace, it fails with an error about a missing symbol. There were also a number of errors showing for postinstall scripts. Where in this process did either I or the install go wrong? Also, we have cygrunsrv operating services if that could have any bearing on this. This is why you got the complaint about cygwin1.dll being busy. When you did the upgrade, did you download the current 'setup.exe' from cygwin.com? Yes. Regards, Gerry -- 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: After installing 1.7.7 command ls is null --now with cygcheck.out
On 1/31/2011 3:49 PM, Gerry Reno wrote: On 01/31/2011 03:00 PM, Larry Hall (Cygwin) wrote: snip This is why you got the complaint about cygwin1.dll being busy. When you did the upgrade, did you download the current 'setup.exe' from cygwin.com? Yes. Hm. There was an issue with 'setup.exe' not properly handling the replacement of the Cygwin DLL on reboot but I thought that was fixed. I'd recommend stopping all your services and reinstalling the Cygwin package. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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.7: Localization does not follow the language of the OS
Replying to http://www.cygwin.com/ml/cygwin/2011-01/msg00399.html: I think that doing setlocale(LC_ALL, ); on application initialization should do the trick. Yes it does - assuming you use a libintl from gettext version = 0.18, and assuming that you have a #include libintl.h in the source file that invokes setlocale (LC_ALL, ). This was implemented in gettext 0.18. I have a #include libintl.h in the source file that invokes setlocale. Now that I look at it again: actually I'm doing setlocale(LC_MESSAGES, ) instead of setlocale(LC_ALL, ), because I only want translation of the message texts. I suppose it shouldn't matter for this discussion, but I mention it anyway, just in case it does matter. I also happen to supply an 'intl' directory with my application, which contains a gettext implementation. It can be activated by giving the --with-included-gettext parameter to the configure script of my application. I tried whether this would fix my problem, but it doesn't; I guess because my included gettext is also version 0.17. Would it help to update my included gettext to version 0.18? Or would this just give me compilation headaches on Cygwin? I noticed that setlocale is not implemented in my included gettext, so I suppose that setlocale has to be supplied by Cygwin anyway. Does this mean that it will never make a difference for me to use the included gettext, or is it possible to somehow influence the behavior of setlocale with the included gettext 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: After installing 1.7.7 command ls is null --now with cygcheck.out
On 01/31/2011 04:14 PM, Larry Hall (Cygwin) wrote: On 1/31/2011 3:49 PM, Gerry Reno wrote: On 01/31/2011 03:00 PM, Larry Hall (Cygwin) wrote: snip This is why you got the complaint about cygwin1.dll being busy. When you did the upgrade, did you download the current 'setup.exe' from cygwin.com? Yes. Hm. There was an issue with 'setup.exe' not properly handling the replacement of the Cygwin DLL on reboot but I thought that was fixed. I'd recommend stopping all your services and reinstalling the Cygwin package. I tried rerunning it but it said nothing to do. How do I force it? Regards, Gerry -- 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: After installing 1.7.7 command ls is null --now with cygcheck.out
On 1/31/2011 4:16 PM, Gerry Reno wrote: On 01/31/2011 04:14 PM, Larry Hall (Cygwin) wrote: On 1/31/2011 3:49 PM, Gerry Reno wrote: On 01/31/2011 03:00 PM, Larry Hall (Cygwin) wrote: snip This is why you got the complaint about cygwin1.dll being busy. When you did the upgrade, did you download the current 'setup.exe' from cygwin.com? Yes. Hm. There was an issue with 'setup.exe' not properly handling the replacement of the Cygwin DLL on reboot but I thought that was fixed. I'd recommend stopping all your services and reinstalling the Cygwin package. I tried rerunning it but it said nothing to do. How do I force it? Yes, that's expected. You need to toggle the Cygwin package to Reinstall. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: After installing 1.7.7 command ls is null --now with cygcheck.out
On 01/31/2011 04:16 PM, Gerry Reno wrote: On 01/31/2011 04:14 PM, Larry Hall (Cygwin) wrote: On 1/31/2011 3:49 PM, Gerry Reno wrote: On 01/31/2011 03:00 PM, Larry Hall (Cygwin) wrote: snip This is why you got the complaint about cygwin1.dll being busy. When you did the upgrade, did you download the current 'setup.exe' from cygwin.com? Yes. Hm. There was an issue with 'setup.exe' not properly handling the replacement of the Cygwin DLL on reboot but I thought that was fixed. I'd recommend stopping all your services and reinstalling the Cygwin package. I tried rerunning it but it said nothing to do. How do I force it? Regards, Gerry Found it. Went into Base and selected Reinstall on Cygwin. I first stopped the services, then reinstalled the cygwin package and then was not prompted to reboot after it finished. And things now appear to work normally. I see this in cygcheck: bash-3.2$ cygcheck -s -r -v | grep -i cygwin1.dll 2586k 2010/08/31 .\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2010/8/31 0:58 2586k 2010/08/31 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2010/8/31 0:58 2586k 2010/08/31 c:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2010/8/31 0:58 Cygwin DLL version info: DLL version: 1.7.7 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 230 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5 Warning: There are multiple cygwin1.dlls on your path bash-3.2$ uname -a CYGWIN_NT-5.2-WOW64 ip-0A7D01FE 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin The installation is behaving normally now. Regards, Gerry -- 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: After installing 1.7.7 command ls is null --now with cygcheck.out
On 1/31/2011 4:42 PM, Gerry Reno wrote: On 01/31/2011 04:16 PM, Gerry Reno wrote: On 01/31/2011 04:14 PM, Larry Hall (Cygwin) wrote: On 1/31/2011 3:49 PM, Gerry Reno wrote: On 01/31/2011 03:00 PM, Larry Hall (Cygwin) wrote: snip This is why you got the complaint about cygwin1.dll being busy. When you did the upgrade, did you download the current 'setup.exe' from cygwin.com? Yes. Hm. There was an issue with 'setup.exe' not properly handling the replacement of the Cygwin DLL on reboot but I thought that was fixed. I'd recommend stopping all your services and reinstalling the Cygwin package. I tried rerunning it but it said nothing to do. How do I force it? Regards, Gerry Found it. Went into Base and selected Reinstall on Cygwin. I first stopped the services, then reinstalled the cygwin package and then was not prompted to reboot after it finished. And things now appear to work normally. OK, good. I thought that would do it. I see this in cygcheck: bash-3.2$ cygcheck -s -r -v | grep -i cygwin1.dll 2586k 2010/08/31 .\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2010/8/31 0:58 2586k 2010/08/31 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2010/8/31 0:58 2586k 2010/08/31 c:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2010/8/31 0:58 Cygwin DLL version info: DLL version: 1.7.7 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 230 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5 Warning: There are multiple cygwin1.dlls on your path In general that looks good. You should check that you actually don't have multiple cygwin1.dlls in your path. If things are working, it's quite possible that you don't but rather just have multiple paths to the 1 DLL you have (i.e. /usr/bin and /bin in your path). If that describes your situation, then you're fine. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: After installing 1.7.7 command ls is null --now with cygcheck.out
On 01/31/2011 04:50 PM, Larry Hall (Cygwin) wrote: On 1/31/2011 4:42 PM, Gerry Reno wrote: On 01/31/2011 04:16 PM, Gerry Reno wrote: On 01/31/2011 04:14 PM, Larry Hall (Cygwin) wrote: On 1/31/2011 3:49 PM, Gerry Reno wrote: On 01/31/2011 03:00 PM, Larry Hall (Cygwin) wrote: snip This is why you got the complaint about cygwin1.dll being busy. When you did the upgrade, did you download the current 'setup.exe' from cygwin.com? Yes. Hm. There was an issue with 'setup.exe' not properly handling the replacement of the Cygwin DLL on reboot but I thought that was fixed. I'd recommend stopping all your services and reinstalling the Cygwin package. I tried rerunning it but it said nothing to do. How do I force it? Regards, Gerry Found it. Went into Base and selected Reinstall on Cygwin. I first stopped the services, then reinstalled the cygwin package and then was not prompted to reboot after it finished. And things now appear to work normally. OK, good. I thought that would do it. I see this in cygcheck: bash-3.2$ cygcheck -s -r -v | grep -i cygwin1.dll 2586k 2010/08/31 .\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2010/8/31 0:58 2586k 2010/08/31 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2010/8/31 0:58 2586k 2010/08/31 c:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2010/8/31 0:58 Cygwin DLL version info: DLL version: 1.7.7 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 230 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5 Warning: There are multiple cygwin1.dlls on your path In general that looks good. You should check that you actually don't have multiple cygwin1.dlls in your path. If things are working, it's quite possible that you don't but rather just have multiple paths to the 1 DLL you have (i.e. /usr/bin and /bin in your path). If that describes your situation, then you're fine. bash-3.2$ whereis -b cygwin1.dll cygwin1: /bin/cygwin1.dll /usr/bin/cygwin1.dll Thanks for the help. Things look ok now. Regards, Gerry -- 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
Windows 2008 64-bit install
I'm trying to install Cygwin on a stock Amazon EC2 Windows 2008 64-bit image. At the end of setup, I get a dialog that says Postinstall script errors with the following information in it: Package: Unknown package 000-cygwin-post-install.sh exit code -1073741819 base-files-mketc.sh exit code -1073741819 base-files-profile.sh exit code -1073741819 bash.sh exit code 35584 coreutils.sh exit code -1073741819 joe.sh exit code -1073741819 man.sh exit code -1073741819 terminfo.sh exit code 35584 terminfo0.sh exit code -1073741819 Some Googling revealed someone else with the identical problem, but no resolution. Following some suggestions, I turned off DEP, but the problem persists. I put all the logs in a zip file here: http://www.slatner.com/quick/cygwinresults.zip Any assistance would be greatly appreciated. -- 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
