Re: DWORD_MAX (was: cvs commit: apr/include apr.hnw)
Jean-Jacques Clar wrote: I will be more than happy to do so, but first will like to ask Allan to grant me permission to APRize the define in apr.hw, win32\sendrecv.c, and win32\readwrite.c. Yes please go ahead, I would do it myself but I'm on v-slow dial up over the weekend. If you don't get to it before Monday I will fix things then. Thanks, Allan
Re: cvs commit: apr/include apr.hnw
At 11:33 AM 9/24/2004, [EMAIL PROTECTED] wrote: clar2004/09/24 09:33:03 added define for DWORD_MAX Could we -please- use an APR decorated name? Bill
DWORD_MAX (was: cvs commit: apr/include apr.hnw)
I will be more than happy to do so, but first will like to ask Allan to grant me permission to APRizethe definein apr.hw, win32\sendrecv.c, and win32\readwrite.c. Thanks, JJ "William A. Rowe, Jr." [EMAIL PROTECTED] 09/24/04 10:48 AM At 11:33 AM 9/24/2004, [EMAIL PROTECTED] wrote:clar 2004/09/24 09:33:03 added define for DWORD_MAXCould we -please- use an APR decorated name?Bill
Re: cvs commit: apr/include apr.hnw
Red flag, this means you break binary compatibility and we had better call that out somehow, if this code is tagged and released before the solution is found. Bill At 02:32 PM 12/13/2003, [EMAIL PROTECTED] wrote: bnicholes2003/12/13 12:32:49 Modified:include apr.hnw Log: large file support is causing problems with acrobat reader and PDF files. Turning it off on NetWare until I can figure out why. Revision ChangesPath 1.42 +5 -1 apr/include/apr.hnw Index: apr.hnw === RCS file: /home/cvs/apr/include/apr.hnw,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- apr.hnw 25 Nov 2003 19:30:02 - 1.41 +++ apr.hnw 13 Dec 2003 20:32:49 - 1.42 @@ -227,7 +227,7 @@ #define APR_HAS_UNICODE_FS0 #define APR_HAS_PROC_INVOKED 0 #define APR_HAS_USER 1 -#define APR_HAS_LARGE_FILES 1 +#define APR_HAS_LARGE_FILES 0 #define APR_HAS_XTHREAD_FILES 0 #define APR_HAS_OS_UUID 0 @@ -262,7 +262,11 @@ typedef size_tapr_size_t; typedef ssize_t apr_ssize_t; +#if APR_HAS_LARGE_FILES typedef off64_t apr_off_t; +#else +typedef off_t apr_off_t; +#endif typedef int apr_socklen_t; /* Are we big endian? */
Re: cvs commit: apr/include apr.hnw
I am only doing this in HEAD not the 2.0 branch. Large file support in the 2.0 branch will remain off as it has always been. Also, I seemed to have found the problem and fixed it. Large file support is turned back on for NetWare. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com William A. Rowe, Jr. [EMAIL PROTECTED] Tuesday, December 16, 2003 9:08:11 AM Red flag, this means you break binary compatibility and we had better call that out somehow, if this code is tagged and released before the solution is found. Bill At 02:32 PM 12/13/2003, [EMAIL PROTECTED] wrote: bnicholes2003/12/13 12:32:49 Modified:include apr.hnw Log: large file support is causing problems with acrobat reader and PDF files. Turning it off on NetWare until I can figure out why. Revision ChangesPath 1.42 +5 -1 apr/include/apr.hnw Index: apr.hnw === RCS file: /home/cvs/apr/include/apr.hnw,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- apr.hnw 25 Nov 2003 19:30:02 - 1.41 +++ apr.hnw 13 Dec 2003 20:32:49 - 1.42 @@ -227,7 +227,7 @@ #define APR_HAS_UNICODE_FS0 #define APR_HAS_PROC_INVOKED 0 #define APR_HAS_USER 1 -#define APR_HAS_LARGE_FILES 1 +#define APR_HAS_LARGE_FILES 0 #define APR_HAS_XTHREAD_FILES 0 #define APR_HAS_OS_UUID 0 @@ -262,7 +262,11 @@ typedef size_tapr_size_t; typedef ssize_t apr_ssize_t; +#if APR_HAS_LARGE_FILES typedef off64_t apr_off_t; +#else +typedef off_t apr_off_t; +#endif typedef int apr_socklen_t; /* Are we big endian? */
Re: cvs commit: apr/include apr.hnw
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 - 1.31
+++ srclib/apr/file_io/unix/seek.c 15 Dec 2003 00:24:05 -
@@ -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 [EMAIL PROTECTED] 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
seek.c.patch
Description: Binary data
apr.hnw.patch
Description: Binary data
apr_arch_file_io.h.patch
Description: Binary data
readwrite.c.patch
Description: Binary data
Re: cvs commit: apr/include apr.hnw
On Sat, 13 Dec 2003 [EMAIL PROTECTED] wrote: bnicholes2003/12/13 12:32:49 Modified:include apr.hnw Log: large file support is causing problems with acrobat reader and PDF files. Turning it off on NetWare until I can figure out why. 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. --Cliff
Re: cvs commit: apr/include apr.hnw
* Cliff Woolley [EMAIL PROTECTED] 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. nd
Re: cvs commit: apr/include apr.hnw
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. :-)
Re: Large file support and .PDF files (was Re: cvs commit: apr/include apr.hnw)
On Sat, Dec 13, 2003 at 01:39:06PM -0700, Brad Nicholes wrote: We have noticed at least on NetWare that enabling large file support causes problems when trying to use acrobat reader in the browser to view a .PDF file. My guess is that this is due to the redefinition of apr_off_t to off64_t rather than off_t. Does anybody have any idea where the incompatibility might be or where I should start looking? Have you checked that APR_OFF_T_FMT is right for apr_off_t == off64_t? (anything that prints an apr_off_t might go wrong otherwise)
Large file support and .PDF files (was Re: cvs commit: apr/include apr.hnw)
We have noticed at least on NetWare that enabling large file support causes problems when trying to use acrobat reader in the browser to view a .PDF file. My guess is that this is due to the redefinition of apr_off_t to off64_t rather than off_t. Does anybody have any idea where the incompatibility might be or where I should start looking? Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Saturday, December 13, 2003 1:32:49 PM bnicholes2003/12/13 12:32:49 Modified:include apr.hnw Log: large file support is causing problems with acrobat reader and PDF files. Turning it off on NetWare until I can figure out why. Revision ChangesPath 1.42 +5 -1 apr/include/apr.hnw Index: apr.hnw === RCS file: /home/cvs/apr/include/apr.hnw,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- apr.hnw 25 Nov 2003 19:30:02 - 1.41 +++ apr.hnw 13 Dec 2003 20:32:49 - 1.42 @@ -227,7 +227,7 @@ #define APR_HAS_UNICODE_FS0 #define APR_HAS_PROC_INVOKED 0 #define APR_HAS_USER 1 -#define APR_HAS_LARGE_FILES 1 +#define APR_HAS_LARGE_FILES 0 #define APR_HAS_XTHREAD_FILES 0 #define APR_HAS_OS_UUID 0 @@ -262,7 +262,11 @@ typedef size_tapr_size_t; typedef ssize_t apr_ssize_t; +#if APR_HAS_LARGE_FILES typedef off64_t apr_off_t; +#else +typedef off_t apr_off_t; +#endif typedef int apr_socklen_t; /* Are we big endian? */
