apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: cvs commit: apr/include apr.hnw
Date Mon, 15 Dec 2003 01:07:25 GMT
  Actually what I have found so far are some 32 bit/64bit type incompatibilies in apr_file_seek(),
especially in the call to setptr().  When large file support is enabled apr_off_t is defined
as off64_t rather than off_t.  But the function setptr() which is used to do the lseek() takes
an unsigned long rather than and apr_off_t.  Also, on the NetWare platform, we need to use
lseek64() in this situation rather than lseek().  Do the linux platforms have a 64 bit lseek()
function?  Below is one of the patches that I plan on commiting later.  Once I cleaned up
these incompatibilities, everything seemed to work correctly.

Brad


Index: srclib/apr/file_io/unix/seek.c
===================================================================
RCS file: /home/cvs/apr/file_io/unix/seek.c,v
retrieving revision 1.31
diff -u -r1.31 seek.c
--- srclib/apr/file_io/unix/seek.c	3 Sep 2003 04:30:50 -0000	1.31
+++ srclib/apr/file_io/unix/seek.c	15 Dec 2003 00:24:05 -0000
@@ -54,7 +54,7 @@
 
 #include "apr_arch_file_io.h"
 
-static apr_status_t setptr(apr_file_t *thefile, unsigned long pos )
+static apr_status_t setptr(apr_file_t *thefile, apr_off_t pos )
 {
     long newbufpos;
     int rc;
@@ -70,7 +70,11 @@
         rc = 0;
     } 
     else {
+#if defined(NETWARE) && APR_HAS_LARGE_FILES
+        rc = lseek64(thefile->filedes, pos, SEEK_SET);
+#else 
         rc = lseek(thefile->filedes, pos, SEEK_SET);
+#endif
 
         if (rc != -1 ) {
             thefile->bufpos = thefile->dataRead = 0;
@@ -117,7 +121,11 @@
     }
     else {
 
+#if defined(NETWARE) && APR_HAS_LARGE_FILES
+        rv = lseek64(thefile->filedes, *offset, where);
+#else 
         rv = lseek(thefile->filedes, *offset, where);
+#endif
         if (rv == -1) {
             *offset = -1;
             return errno;
@@ -131,7 +139,11 @@
 
>>> Cliff Woolley <jwoolley@virginia.edu> Saturday, December 13, 2003 11:45:12
PM >>>
On Sun, 14 Dec 2003, [ISO-8859-15] André Malo wrote:

> > Acrobat Reader is just about the only client I know of that actually uses
> > byte range requests.  So if PDF serving to acroread is broken, the
> > byterange filter is virtually always the culprit.
>
> Nah, every download manager (e.g. wget) uses them.

Ahh, that's handy to know... I don't actually use download managers so
I've never seen it in anything but acroread.  But anyway, my guess that
the byterange filter is likely involved stands.  :-)

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 


Mime
View raw message