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
>> 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
cygch
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
hristopher 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.
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
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
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 wi
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: Ple
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.
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 lis
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
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 i
12 matches
Mail list logo
