UW imapd and cygwin1.dll 1.3.13-2
The binary imapd.exe provided by UW has been working great prior to cygwin1.dll 1.3.13-2. Now, imapd.exe cannot load (and sorry, I don't have the error available right offhand). It is not a problem with ntsec; I have been running with ntsec for some time, and setting nontsec doesn't help. The issue is that 1.3.13-2 has some new logic to preclude multiple cygwin1.dll versions (right?). In the past, I was able to get away with having an old cygwin1.dll living in the imapd.exe directory, and it would happily run with the old version (shame on me!). Now it will not load. The multiple cygwin1.dll version is generally a good idea, but for old apps with only binaries available, it was nice to use multiple copies sparingly. It would be nice to have a CYGWIN variable to disable the strict multiple cygwin1.dll version checking feature. I know that I will regret this post... Apologies in advance. D. Knisely -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: UW imapd and cygwin1.dll 1.3.13-2
Thank you for the information. I have tried three binary versions of imapd (all different) and have built my own binary. All four versions have the same behavior which is new to cygwin1.dll version 1.3.13-2. imapd will load. With cygwin1.dll version 1.3.12 (and various earlier versions), imapd worked very well with MS Outlook. When I try it with 1.3.13-2, Outlook hangs (as well as imapd). When I do an strace on the imapd process, I get: $ strace -p 3240 Attached to pid 3240 (windows pid 3008) 6 6 [sig] imapd 3240 wait_sig: looping It looks like something has changed in 1.3.13-2 related to poll or waiting for signals? Possibly there has always been a race condition that is now occurring 100% of the time with 1.3.13-2, but never occurred with previous versions. Has anything changed related to polling/waiting for signals in 1.3.13? Doug Knisely *** Joshua Daniel Franklin ([EMAIL PROTECTED]) wrote today: :) > The multiple cygwin1.dll version is generally a good idea, but for :) > old apps with only binaries available, it was nice to use multiple :) > copies sparingly. It would be nice to have a CYGWIN variable to :) > disable the strict multiple cygwin1.dll version checking feature. :) :) I don't know if this would help you, but UW does provide source at: :) :) http://www.washington.edu/imap/ :) :) I also think the same fellow who ported Pine to cygwin had gotten imapd :) to compile as well... Eduardo Chappa (sorry if misspelled). :) :) Besides that, you'll have to get some details on why it won't start or :) what kind of errors it gives with only the latest DLL in your path. Let me tell you my part of the story. I have compiled the imapd server, and as to how I understand that it should work, it works. However, one of the people in this forum tells me that it does not work for him. James Grishaw maintains the Cygwin port of the UW-IMAP server, which can be found here. http://sourceforge.net/projects/uw-imap-cygwin/ A couple of weeks ago I was trying to set up an IMAP server in my laptop, which runs Windows 2000 Pro, and tried my version of the server, and it wouldn't work. I downloaded the version of the server from the web page above, and it wouldn't work either (somehow, both servers made the same mistake, and they would not find the location of a folder). Frustrated enough by having failed, I had to reboot my laptop in some moment, and after I rebooted, the server distributed by James started working. I did not try it (nor I can try it now), but I assume that both servers should work after rebooting. I don't why one needs to reboot, or why I needed to reboot (I had tried my server before, and it used to work, without rebooting, strange...) My version of the imap server (and some other tools) can be found in this web page: http://www.math.washington.edu/~chappa/pine/info/cygwin.html -- Eduardo http://www.math.washington.edu/~chappa/pine/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: UW imapd and cygwin1.dll 1.3.13-2
Chris: Sorry to not make the correlation with the other problems; none of them seemed similar enough. I guess that I didn't catch the right threads. As I'm sure you already know, the latest snapshot seems to fix the problem. Thanks! Doug Knisely > Check other threads in the cygwin mailing list. This is always a good plan > when you have a problem. > > If you had done so, you would have noticed other people reporting > similar problems and me suggesting that they run the latest snapshot. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: UW imapd and cygwin1.dll 1.3.13-2
As I responded earlier, the 1.3.13 snapshot did fix the problem with UW imapd. However, all actual releases of the cygwin1.dll since that time have result in the same broken behavior (hangs waiting in a poll waiting for some signal). I tried all intermediate versions up to 1.3.15-2 with no luck. At this point, I am stuck back at 1.3.12. Is there anything different between the fix in the snapshot after 1.3.13-2 vs. the actual releases later? Any suggestion on what I might try? By the way, for other imapd users, this problem only occurs when used with Microsoft's Outlook IMAP implementation; other IMAP clients work OK, so it is something unique to the way Outlook uses IMAP services. D. Knisely >>It looks like something has changed in 1.3.13-2 related to poll or waiting >>for signals? Possibly there has always been a race condition that is now >>occurring 100% of the time with 1.3.13-2, but never occurred with previous >>versions. >> >>Has anything changed related to polling/waiting for signals in 1.3.13? >Check other threads in the cygwin mailing list. This is always a good plan >when you have a problem. >If you had done so, you would have noticed other people reporting >similar problems and me suggesting that they run the latest snapshot. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Please try latest snapshot
FWIW (quite a lot to me, actually), my mysterious UW imapd hanging problem went away with this snapshot of cygwin1.dll (1121). D. Knisely -Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 10:54 PM To: [EMAIL PROTECTED] Subject: Re: Please try latest snapshot On Thu, Nov 21, 2002 at 11:47:22PM -0500, Christopher Faylor wrote: >I'm regenerating a snapshot right now which may become 1.3.16. >Please try it. Please try the later of a 2002-11-21 or 2002-11-22 >snapshot. > >FWIW, I was able to duplicate the "emacs hangs if you resize the screen" >problem twice with the previous version of cygwin. I could not >duplicate it at all with this version. > >Thanks, >cgf Forgot my signature. -- Please do not send me personal email with cygwin questions or observations. Use the resources at http://cygwin.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Please try latest snapshot
Spoke too soon; latest snapshot is much better with UW imapd and Outlook/IMAP (i.e., doesn't hang 100%), but still hangs every 10 minutes or so. Seems to be a less likely race condition problem or something. >FWIW (quite a lot to me, actually), my mysterious UW imapd hanging problem >went away with this snapshot of cygwin1.dll (1121). >D. Knisely -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Process hang(100% CPU Usage) when concurrent calling select(),cygwin1.5.5-1 WinXP/Win2000
Just thought that I would report that the 1108 snapshot also solved a similar problem with privoxy using 100% of CPU (also apparently on select, which is basically where that program spins all the time) occasionally under high load. I wanted to test for a few days to make sure it was gone. Thanks for the fix! Doug Knisely -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Can't Read /cygdrive/c in snapshots from 1108 on (unknown windows error 122)
Please excuse me if this has been reported previously, but I can't seem to find it mentioned in the archives. Starting with the 20031108 snapshot on (for each snapshot after that), I cannot read the "c:/" or "/cygdrive/c" drive. If I restore to any version of cygwin1.dll earlier that that, I get the normal expected behavior. An strace is excerpted below. It seems to go astray at "unknown windows error 122": "326 58973 [main] ls 3428 seterrno_from_win_error: /netrel/src/cygwin-snapsho t-20031119-1/winsup/cygwin/security.cc:1101 windows error 122" The same results come from any program that tried to enumerate the /cygdrive/c directory (e.g., perl, bash filename expansion, etc.). This problem definitely started only with the recent snapshots (which I need to run because of the select() 100% CPU problem that is fixed in these snapshots). D. Knisely -- strace excerpt: $ strace ls /cygdrive/c >trace.out ls: /cygdrive/c: Permission denied trace output: [.] 298 57280 [main] ls 3428 symlink_info::check: not a symlink 58 57338 [main] ls 3428 symlink_info::check: 0 = symlink.check (c:\, 0x22F5 30) (0x220) 60 57398 [main] ls 3428 path_conv::check: root_dir(c:\), this->path(c:\), s et_has_acls(8) 64 57462 [main] ls 3428 build_fh_pc: fh 0x61681384 56 57518 [main] ls 3428 stat_worker: (/cygdrive/c, 0x100223E8, 1, 0x6168138 4), file_attributes 54 66 57584 [main] ls 3428 fhandler_base::open: (c:\, 0x11) query_open 1 119 57703 [main] ls 3428 fhandler_base::open: 0x70C = CreateFile (c:\, 0x0, 0x7, 0x22FC80, 0x3, 0x281, 0) 61 57764 [main] ls 3428 fhandler_base::set_flags: flags 0x11, supplied_ bin 0x2 57 57821 [main] ls 3428 fhandler_base::set_flags: O_TEXT/O_BINARY set in fl ags 0x1 56 57877 [main] ls 3428 fhandler_base::set_flags: filemode set to binary 56 57933 [main] ls 3428 fhandler_base::open: 1 = fhandler_base::open (c:\, 0x11) 57 57990 [main] ls 3428 fhandler_base::open_fs: 1 = fhandler_disk_file::ope n (c:\, 0x11) 81 58071 [main] ls 3428 fhandler_base::fstat_by_handle: 1 = GetFileInformat ionByHandle (c:\, 1804) 514 58585 [main] ls 3428 get_file_attribute: file: c:\ 62 58647 [main] ls 3428 read_sd: file = c:\ 326 58973 [main] ls 3428 seterrno_from_win_error: /netrel/src/cygwin-snapsho t-20031119-1/winsup/cygwin/security.cc:1101 windows error 122 66 59039 [main] ls 3428 geterrno_from_win_error: unknown windows error 122, setting errno to 13 59 59098 [main] ls 3428 get_nt_attribute: read_sd Win32 error 122 57 59155 [main] ls 3428 fhandler_base::fstat_helper: 0 = fstat (, 0x100223E 8) st_atime=3FBE682B st_size=0, st_mode=0x4000, st_ino=5, sizeof=96 62 59217 [main] ls 3428 fhandler_base::close: closing '/cygdrive/c' handle 0x70C 78 59295 [main] ls 3428 stat_worker: 0 = (/cygdrive/c, 0x100223E8) 518 59813 [main] ls 3428 normalize_posix_path: src /cygdrive/c 59 59872 [main] ls 3428 normalize_posix_path: /cygdrive/c = normalize_posix _path (/cygdrive/c) 58 59930 [main] ls 3428 mount_info::conv_to_win32_path: conv_to_win32_path (/cygdrive/c) 61 59991 [main] ls 3428 mount_info::cygdrive_win32_path: src '/cygdrive/c', dst 'c:\' 57 60048 [main] ls 3428 set_flags: flags: text (0x200) 159 60207 [main] ls 3428 mount_info::conv_to_win32_path: src_path /cygdrive/ c, dst c:\, flags 0x220, rc 0 266 60473 [main] ls 3428 symlink_info::check: not a symlink 58 60531 [main] ls 3428 symlink_info::check: 0 = symlink.check (c:\, 0x22F6 20) (0x220) 61 60592 [main] ls 3428 path_conv::check: root_dir(c:\), this->path(c:\), s et_has_acls(8) 65 60657 [main] ls 3428 build_fh_pc: fh 0x61681384 329 60986 [main] ls 3428 read_sd: file = c:\ 141 61127 [main] ls 3428 seterrno_from_win_error: /netrel/src/cygwin-snapsho t-20031119-1/winsup/cygwin/security.cc:1101 windows error 122 63 61190 [main] ls 3428 geterrno_from_win_error: unknown windows error 122, setting errno to 13 58 61248 [main] ls 3428 check_file_access: flags 4, ret -1 225 61473 [main] ls 3428 writev: writev (2, 0x22DD40, 1) 60 61533 [main] ls 3428 fhandler_console::write: 22DDD0, 4 56 61589 [main] ls 3428 fhandler_console::write: at 108(l) state is 0 733 62322 [main] ls 3428 fhandler_console::write: 4 = write_console (,..4) 67 62389 [main] ls 3428 writev: 4 = write (2, 0x22DD40, 1), errno 13 68 62457 [main] ls 3428 writev: writev (2, 0x22DD60, 1) 57 62514 [main] ls 3428 fhandler_console::write: 22DDF0, 11 55 62569 [main] ls 3428 fhandler_console::write: at 47(/) state is 0 142 62711 [main] ls 3428 fhandler_console::write: 11 = write_console (,..11) 60 62771 [main] ls 3428 writev: 11 = write (2, 0x22DD60, 1), errno 13 69 62840 [main] ls 3428 writev: writev (2, 0x22DD40, 1) 57 62897 [main] ls 3428 fhandler_console::write: 22DDD0, 19 72 62969 [main] ls 3428 fhandler_console::write: at 58(:) s
RE: Can't Read /cygdrive/c in snapshots from 1108 on (unknown windows error 122)
As is indicated in the strace messages (and I thought I made clear, but I guess I didn't), I was using the 1119 snapshot. Worse yet, I get the same result with the newer 1121 snapshot. Any idea what I should try? I tried rebooting in case something was hanging around in memory from the old DLL, but I get the same results. Is this any hint: $ pwd / $ ls -l cygdrive total 0 d- 29 0 Nov 22 11:51 c/ $ ls -ld cygdrive dr-xr-xr-x4 00 0 Dec 31 1969 cygdrive/\ D. Knisely >> -Original Message- >> From: Christopher Faylor [mailto:[EMAIL PROTECTED] >> Sent: Friday, November 21, 2003 2:18 PM >> To: [EMAIL PROTECTED] >> Subject: Re: Can't Read /cygdrive/c in snapshots from 1108 on (unknown >> windows error 122) >> >> On Fri, Nov 21, 2003 at 01:42:27PM -0600, D. N. Knisely wrote: >> >Starting with the 20031108 snapshot on (for each snapshot after that), I >> >cannot read the "c:/" or "/cygdrive/c" drive. If I restore to any >> version >> >of cygwin1.dll earlier that that, I get the normal expected behavior. >> An >> >strace is excerpted below. It seems to go astray at "unknown windows >> error >> >122": >> >> When reporting errors with snapshots or with cvs versions of cygwin, >> always make sure that you are using the latest. A new snapshot was >> released on 2003-11-19 which fixes this problem. >> >> cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Can't Read /cygdrive/c in snapshots from 1108 on (unknown windows error 122)
OK. I will have to assume that you objected to the lack of cygcheck.out, so here it is. D. Knisely >> -Original Message- >> From: Christopher Faylor [mailto:[EMAIL PROTECTED] >> Sent: Saturday, November 22, 2003 3:12 PM >> To: [EMAIL PROTECTED] >> Subject: Re: Can't Read /cygdrive/c in snapshots from 1108 on (unknown >> windows error 122) >> >> On Sat, Nov 22, 2003 at 12:03:31PM -0600, D. N. Knisely wrote: >> >As is indicated in the strace messages (and I thought I made clear, but >> I >> >guess I didn't), I was using the 1119 snapshot. >> >> Which brings us back to http://cygwin.com/problems.html . Since I have >> no way of knowing what you're running, given that this problem had been >> recently fixed, I will always assumed cockpit error. cygcheck.out Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Can't Read /cygdrive/c in snapshots from 1108 on (unknown windows error 122)
I unmounted those mounts: $ mount C:\cygwin\usr\X11R6\lib\X11\fonts on /usr/X11R6/lib/X11/fonts type system (binmo de) C:\cygwin\bin on /usr/bin type system (textmode) C:\cygwin\lib on /usr/lib type system (textmode) C:\cygwin on / type system (textmode) c: on /cygdrive/c type user (textmode,noumount) No change. Am I supposed to have an actual directory entry for cygdrive? There is a directory there: $ pwd / $ ls -l cygdrive total 0 d- 29 0 Nov 24 07:09 c/ $ ls -ld cygdrive dr-xr-xr-x4 00 0 Dec 31 1969 cygdrive/ It doesn't seem to make any different if I rename it to something else; I gather that /cygdrive is actually a virtual drive like /dev. D. Knisely >> -Original Message- >> From: Christopher Faylor [mailto:[EMAIL PROTECTED] >> Sent: Sunday, November 23, 2003 12:06 PM >> To: [EMAIL PROTECTED] >> Subject: Re: Can't Read /cygdrive/c in snapshots from 1108 on (unknown >> windows error 122) >> >> On Sun, Nov 23, 2003 at 10:17:13AM -0600, D. N. Knisely wrote: >> >OK. I will have to assume that you objected to the lack of cygcheck.out, >> so >> >here it is. >> >> c:\Documents and Settings\dnk /cygdrive/c/Documents and Settings/dnk >> system binmode >> c:\Inetpub /cygdrive/c/Inetpub >> system binmode >> c:\Inetpub\wwwroot\contributions >> /cygdrive/c/Inetpub/wwwroot/contributions system binmode >> >> I would bet that the above settings can't be helping much. Using >> /cygdrive >> in the target for a mount is not a good idea. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated: cygwin-1.5.12-1
This load fixed one of those "strange network problems" for me as well. Name service (gethostbyname) did not work in processes spawned out of CGI scripts running under apache. I was guessing it was something missing in the environment, but could not track it down to SYSTEMROOT. Now it works again. Thanks! D. Knisely -Original Message- From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] Sent: Thursday, November 11, 2004 3:00 PM To: [EMAIL PROTECTED] Subject: Re: [ANNOUNCEMENT] Updated: cygwin-1.5.12-1 Gack. Subject change. Igor On Thu, 11 Nov 2004, Christopher Faylor wrote: > I've made a new version of the Cygwin DLL and associated utilities > available for download. As usual, a list of what has changed is below. > > To update your installation, click on the "Install Cygwin now" link on > the http://cygwin.com/ web page. This downloads setup.exe to your > system. Then, run setup and answer all of the questions. > > If you have questions or comments, please send them to the Cygwin > mailing list at: [EMAIL PROTECTED] . > > *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** > > If you want to unsubscribe from the cygwin-announce mailing list, look > at the "List-Unsubscribe: " tag in the email header of this message. > Send email to the address specified there. It will be in the format: > > [EMAIL PROTECTED] > > If you need more information on unsubscribing, start reading here: > > http://sources.redhat.com/lists.html#unsubscribe-simple > > Please read *all* of the information on unsubscribing that is available > starting at this URL. > > Christopher Faylor > TimeSys, Inc. > > Changes since 1.5.11-1: > > - Fix problem where stdout was closed when a thread exits. (Christopher Faylor) > > - Fix pipe problems with Windows 95. (Bas van Gompel) > > - Fix race condition in fork which occasionally caused bash to think a forked > process had died prematurely. (Christopher Faylor) > > - Properly deal with CTRL-C while a cygwin process is in startup code. > (Pierre Humblet) > > - Handle RTLD_DEFAULT in dlsym. (Sam Steingold) > > - Don't try to use Windows "delete on close" for files on remote shares. > (Corinna Vinschen) > > - Properly handle trailing dots in windows file names. (Pierre Humblet) > > - Make the default /cygdrive "binary mode". (Christopher Faylor) > > - Add siginterrupt declaration to signal.h. (Christopher Faylor) > > - Use proper wait value for tty reads. (Mark Paulus) > > - Properly reset SIGCHLD blocking after a spawn when there was no previous > signal blocking. (Christopher Faylor) > > - Work hard to ensure that SYSTEMROOT environment variable is always passed > to new processes even when it has ostensibly been deleted. This should > fix some strange network problems. (Corinna Vinschen) > > - Fix network slowdowns experienced by some firewall users. > (Christopher Faylor) > > - Fix return value for unbuffered fread. (Jason Tishler) > > - Properly load registry hives and insure access to system mounts. > (Pierre Humblet) > > - Cleanup cygcheck and getfacl output. (Bas van Gompel) > > - Add cygcheck warning about multiple cygwin DLLs. (Bas van Gompel) -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
