Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3CF4CA4C.8EE1E771@insight.rr.com> Date: Wed, 29 May 2002 08:32:13 -0400 From: Paul McFerrin Reply-To: pmcferrin AT insight DOT rr DOT com X-Accept-Language: en,pdf MIME-Version: 1.0 To: djnews AT thedixons DOT com, cygwin AT cygwin DOT com Subject: Re: Apache 1.3.22 on cygwin under XP - loosing data References: <000501c20556$c66b43c0$bd7ba8c0 AT q6f3d6> <3CF297BF DOT 828BE2F AT insight DOT rr DOT com> <000801c205c8$08f07690$bd7ba8c0 AT q6f3d6> <3CF2FD22 DOT D8A5D3B9 AT insight DOT rr DOT com> <000701c206dc$f66a7960$bd7ba8c0 AT q6f3d6> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dan: I had to rebase everything manually myself. Without the rebase, the httpd processes could not even complete a fork! The arguments that I used were the same used by someone else for a different application and not specificially Apache. I've asked someone to shed some light on educating me on just what those arguments mean so I don't have to be in the dark on this subject. Heck I really don't know if they are suitable for Apache. I too would like to get this issue resolved. Jason are you listening? -paul mcferrin djnews AT thedixons DOT com wrote: > > I'm clueless at this point, sorry. It'd sure be nice to get this working > though. > By the way, is that rebase command being run in an install somewhere or > did you run that manually? As far as I know, I didn't run it anywhere. > > -dan > > ----- Original Message ----- > From: "Paul McFerrin" > To: > Sent: Monday, May 27, 2002 9:44 PM > Subject: Re: Apache 1.3.22 on cygwin under XP - loosing data > > > I just downloaded an .exe file that was larger tnan 1MB. When I did a > comparison of the > > downloaded file with the original file, the byte offset of the first > incorrect byte was at > > 32769. I repeated this experiment with another .exe file and again the > first incorrect byte > > was at 32769. The incorrect bytes continued until the end of the file. > > > > This seems to substantiate your theory of the 32K boundary. > > > > I would like for someone to explain to me what the following command is > doing to the DLL's: > > $ rebase -d -b 0x68000000 -o 0x10000 ... file > > Could it be that the values supplied might not be totally correct for this > application? > > Since I really have no knowledge, making adjustment to these values would > definitely put me > > into the dark. > > > > This is my last application to be moved over to the XP platform. Once it > is move, I will > > have a surplus machine. > > > > -Paul McFerrin > > > > djnews AT thedixons DOT com wrote: > > > > > > I agree with what you found. I now can get it to fail on plain html > text as > > > well. > > > It usually starts to corrupt bits at around the 32K point. I can pull > up > > > hundreds > > > of thumbnails (~10-20K) without a problem. Out of hundreds of bigger > > > jpgs, 100% of the bad ones are >32K and 100% of the bad ones are <40K > > > (but it is not a clean break at 32K). Also, text htmls go bad around > the > > > same > > > point. I have actually gotten it to pick up what looks like data from > > > another > > > file on disk! I have seen that behavior 3 or 4 times. > > > > > > I have tried the httpd binary that came with the cygwin distribution as > well > > > as the build you can link to on the "Software" page. They both fail. > > > I know they are the same revision (Apache/1.3.24 (cygwin)) but they are > > > wildly differrent sizes so I figured I'd try them both. > > > > > > I have not yet download the win32 build at apache.org but I might try > > > that next. > > > > > > -dan > > > ----- Original Message ----- > > > From: "Paul McFerrin" > > > To: "Dan Dixon" ; > > > Sent: Monday, May 27, 2002 2:31 PM > > > Subject: Re: Apache 1.3.22 on cygwin under XP - loosing data > > > > > > > Nice thought... I did verify that all of the mounts are binmode > mounts. > > > > > > > > I saved one of the bad images that the browser downloaded and compared > it > > > with the original > > > > file on disk. Here is what I've observed.... > > > > - The two files (good & bad) were identical in size! > > > > - The bad file did contain some \n and \r but there were not adjacent. > > > > > > > > I did a "cmp good_file bad_file" and here is a partial output: > > > > 32769 172 0 > > > > 32771 377 341 > > > > 32772 0 303 > > > > 32773 274 0 > > > > 32774 333 0 > > > > 32775 234 342 > > > > 32776 204 303 > > > > 32777 50 22 > > > > 32778 262 0 > > > > 32779 7 0 > > > > 32780 146 0 > > > > 32781 41 265 > > > > ... > > > > > > > > As you can see, it is NOT a cr/nl problem. It looks like bits are > getting > > > dropped. Another > > > > thing to note, I can purge my cache and reload the page. The reloaded > > > page is still screwey > > > > but NOT in an identical fashion. If it was a cr/nl problem, I would > > > expect it to be > > > > reproducable. > > > > > > > > -paul mcferrin > > > > > > > > > > > > Dan Dixon wrote: > > > > > > > > > > I have the same problem with the install I did tonight. > > > > > Just a guess, but you know what it looks like? It looks > > > > > like a text/binary mode issue. Any picture that has a cr/lf > > > > > in it will get trashed, but not every picture. I'm going to > > > > > write a perl script to check for this and see if it lines up > > > > > with the pictures that are getting trashed. Now I have > > > > > now idea how to fix this :) > > > > > > > > > > -dan > > > > > > > > > > > > > > -- > > > 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/ > > > > -- 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/