Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of jorton@redhat.com designates
 66.187.233.31 as permitted sender)
Date: Wed, 8 Feb 2006 09:39:28 +0000
From: Joe Orton <jorton@redhat.com>
To: Garrett Rooney <rooneg@electricjellyfish.net>
Cc: APR Developer List <dev@apr.apache.org>
Subject: Re: [PATCH] large files, seek, and unsigned longs
Message-ID: <20060208093928.GB20394@redhat.com>
Mail-Followup-To: Garrett Rooney <rooneg@electricjellyfish.net>,
	APR Developer List <dev@apr.apache.org>
References: <7edfeeef0602072116p41e25c3el71000e55f12d0a14@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <7edfeeef0602072116p41e25c3el71000e55f12d0a14@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i

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?

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

Regards,

joe