Bug 9185

Summary:	Downloaded files always corrupt on CYGWIN
Product:	Apache httpd-2	Reporter:	Jason Fu <tsfu>
Component:	Core	Assignee:	Apache HTTPD Bugs Mailing List <bugs>
Status:	CLOSED FIXED
Severity:	normal	CC:	tsfu
Priority:	P3
Version:	2.0.36
Target Milestone:	---
Hardware:	PC
OS:	other

Description Jason Fu 2002-05-17 00:13:25 UTC

When a binary file is hosted by Apache 2.0.36 or 1.3.24 compiled by CYGWIN, 
the downloaded file is always corrupted. The precompiled version does not have 
the same problem but it does not respond when a client tries to download a big 
file after (say) half an hour.

Comment 1 William A. Rowe Jr. 2002-05-17 00:50:29 UTC

Which version of Windows are you running under cygwin?  If XP ... 
please follow through on the recommendations noted under "XP Users 
Read Me First" ...

http://www.apache.org/dist/httpd/binaries/win32/

Comment 2 Cliff Woolley 2002-05-17 01:15:38 UTC

If the WinXP thing isn't the problem, how about the following changes?

Index: http_core.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v
retrieving revision 1.311
diff -u -d -r1.311 http_core.c
--- http_core.c 21 Mar 2002 14:52:55 -0000      1.311
+++ http_core.c 17 May 2002 01:12:25 -0000
@@ -3834,7 +3834,7 @@
         return METHOD_NOT_ALLOWED;
     }
 
-#if defined(OS2) || defined(WIN32) || defined(NETWARE)
+#if defined(OS2) || defined(WIN32) || defined(NETWARE) || defined(CYGWIN)
     /* Need binary mode for OS/2 */
     f = ap_pfopen(r->pool, r->filename, "rb");
 #else
Index: open.c
===================================================================
RCS file: /home/cvs/apr/file_io/unix/open.c,v
retrieving revision 1.94
diff -u -d -r1.94 open.c
--- open.c      20 Mar 2002 08:54:42 -0000      1.94
+++ open.c      17 May 2002 01:13:13 -0000
@@ -152,6 +152,11 @@
     if (flag & APR_TRUNCATE) {
         oflags |= O_TRUNC;
     }
+#ifdef O_BINARY
+    if (flag & APR_BINARY) {
+        oflags |= O_BINARY;
+    }
+#endif
     
     if (perm == APR_OS_DEFAULT) {
         (*new)->filedes = open(fname, oflags, 0666);

Comment 3 William A. Rowe Jr. 2002-05-17 02:20:17 UTC

  That hack is looking pretty gross.

  Isn't there a means to pretest this situation with autoconf?  Create
  a 'text' file of XXX\n and then test if the file remains 4 bytes?
  Then set APR_FILE_HAS_LF_TRANSLATION ?

Comment 4 Cliff Woolley 2002-05-17 02:49:38 UTC

We *could* do that, but how would you implement it?  Well, okay, better 
question.  Which part are you saying is ugly?  The 1.3 part?  Okay, I'll agree 
with that.  But that's not autoconf.  For the 2.0 part, why is that ugly?  All 
we're saying is that apr_file_open should respect the APR_BINARY flag if the 
platform cares about it (in which case O_BINARY would be defined in fcntl.h).  
The APR change seems totally right to me.

Comment 5 Jason Fu 2002-05-17 09:05:00 UTC

I've checked 2.0.36 and 1.3.24 compiled by CYGWIN on WinXP, Win2K and Win .Net 
Enterprise Beta 3615. They all have the same problem - corrupted file download. 
And there's no such a problem on 2.0.36 (Win32) version on WinXP at all. I'm 
using the latest CYGWIN available from www.cygwin.com. I think I'm going to let 
CYGWIN know about it too.

Comment 6 William A. Rowe Jr. 2002-05-17 12:25:34 UTC

  N'er mind... those patches look just fine!  [I read the 1.3 patch for 2.0].

Comment 7 Cliff Woolley 2002-05-17 18:10:33 UTC

I committed the patches I posted earlier in this PR, so this is fixed in CVS for both 
1.3.25 and 2.0.37.  Thanks for the report!