apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: [PATCH] large files, seek, and unsigned longs
Date Wed, 08 Feb 2006 15:55:00 GMT
On 2/8/06, Joe Orton <jorton@redhat.com> wrote:
> On Tue, Feb 07, 2006 at 09:16:41PM -0800, Garrett Rooney wrote:
> > 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.
> That's not necessary, and will introduce bugs for people using fsfs and
> APR 0.9.x - did you read the warning note in apr_file_io.h?

Strangely enough, during my initial testing I SWEAR I had to add this
in order to stop getting killed off by "file too big" signals, but now
that I test with just the apr_off_t fix it seems to work just fine,
and looking at the code I can't see how the APR_LARGEFILE would have
made any difference at all.  Weird.  Oh well, one less change I need
to make ;-)

> > 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.
> Nice catch, this is a file opened with APR_BUFFERED, right?  That's the
> only time this patch should make a difference. I'll add some test cases
> for that combination.

Yes, it was buffered.  I was going to add a test, but I wasn't quite
sure how to do it in such a way that won't drop giant files on
people's hard drives when sparse files aren't supported...


View raw message