You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by bn...@apache.org on 2003/12/13 21:32:49 UTC
cvs commit: apr/include apr.hnw
bnicholes 2003/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 Changes Path
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 -0000 1.41
+++ apr.hnw 13 Dec 2003 20:32:49 -0000 1.42
@@ -227,7 +227,7 @@
#define APR_HAS_UNICODE_FS 0
#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_t apr_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
Posted by Cliff Woolley <jw...@virginia.edu>.
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: cvs commit: apr/include apr.hnw
Posted by André Malo <nd...@perlig.de>.
* Cliff Woolley <jw...@virginia.edu> 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
Posted by Cliff Woolley <jw...@virginia.edu>.
On Sat, 13 Dec 2003 bnicholes@apache.org wrote:
> bnicholes 2003/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
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
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, bnicholes@apache.org wrote:
>bnicholes 2003/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 Changes Path
> 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 -0000 1.41
> +++ apr.hnw 13 Dec 2003 20:32:49 -0000 1.42
> @@ -227,7 +227,7 @@
> #define APR_HAS_UNICODE_FS 0
> #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_t apr_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? */
>
>
>