Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of rooneg@gmail.com designates
 64.233.184.198 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:mime-version:content-type;
        b=T1gNwoiWmw4v3Yyw5qRyTG29O+TrdJyUZzcozuzr1f1mOZFqfz297zDqC7/TRx1Fw1S9zG0mwYqaPVt6+S7ya9sNVKxh6Bub94TFwfaQeEt+yj+k9p34rbxTZJmciS+C4YivOgOeCFRtACyFpgQrMEz2V7hvjNSluimUCEHznwc=
Message-ID: <7edfeeef0602072116p41e25c3el71000e55f12d0a14@mail.gmail.com>
Date: Tue, 7 Feb 2006 21:16:41 -0800
From: Garrett Rooney <rooneg@electricjellyfish.net>
Sender: rooneg@gmail.com
To: APR Developer List <dev@apr.apache.org>
Subject: [PATCH] large files, seek, and unsigned longs
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_Part_2233_18339743.1139375801736"

------=_Part_2233_18339743.1139375801736
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

So I've been tracing a Subversion bug where fsfs repositories fall
down hard when you commit enough data in one revision to result in a
revfile that's larger than 2 gigs.  It turns out that the problem was
twofold.

First, we weren't passing APR_LARGEFILE to apr_file_open, which is easy to =
fix.

Second, and more worrying, seeking to the end of a really big file
results in an offset that's short of the actual length of the file.=20
The reason is that apr_file_t's filePtr member is an unsigned long,
and on a LFS system where apr_off_t is 64 bits that results in the
offset getting truncated.  Changing filePtr to an apr_off_t fixes the
problem, and I can't see anything wrong with making that change, but
I'd love a second set of eyes on this.

An interesting note is that Netware and Win32 already use apr_off_t
for this member, the only place other than Unix that doesn't is OS/2,
so someone familiar with the OS/2 code should probably look into
correcting this problem there.

Anyway, here's the patch, let me know what you think.

-garrett

------=_Part_2233_18339743.1139375801736
Content-Type: text/x-patch; name=fix-64bit-seeks.diff; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Attachment-Id: f_ejf6wsv8
Content-Disposition: attachment; filename="fix-64bit-seeks.diff"

Index: include/arch/unix/apr_arch_file_io.h
===================================================================
--- include/arch/unix/apr_arch_file_io.h	(revision 375855)
+++ include/arch/unix/apr_arch_file_io.h	(working copy)
@@ -107,7 +107,7 @@
     apr_size_t bufsize;       /* The size of the buffer */
     unsigned long dataRead;   /* amount of valid data read into buffer */
     int direction;            /* buffer being used for 0 = read, 1 = write */
-    unsigned long filePtr;    /* position in file of handle */
+    apr_off_t filePtr;        /* position in file of handle */
 #if APR_HAS_THREADS
     struct apr_thread_mutex_t *thlock;
 #endif

------=_Part_2233_18339743.1139375801736--