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.
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
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
