[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] APR_LARGEFILE and svn_io_file_open

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-02-08 16:57:20 CET

On 2/8/06, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> On Tue, Feb 07, 2006 at 09:27:31PM -0800, Garrett Rooney wrote:
> > In tracking down issue 2453 (commits that create fsfs revfiles greater
> > than 2gigs crash and burn on linux) I noticed that we don't pass
> > APR_LARGEFILE to svn_io_file_open in all the places where we need to.
> > Specifically, we do in a few spots related to hotcopying stuff, but we
> > don't in fs_fs.c when we open potentially huge files like revfiles.
> >
>
> We don't need to seek when hotcopying, but we need to be able to seek in
> a revfile. I agree with David-quoting-Greg: this is a bad idea on APR
> 0.9, because it'll either cause us to write some data that's corrupt,
> or alternatively will cause us to error out when trying to seek to the
> trailer line (at the end of the revfile).
>
> This might make sense for APR 1.x, but I'm surprised that APR doesn't
> just pass O_LARGEFILE unconditionally now - why is that?

Actually, it turns out I was mistaken, we don't need to pass
APR_LARGEFILE to make things work, just fixing the filePtr variable
type fixes things. I SWEAR when I initially tested this it was
needed, but I must have seen that behavior in one of the strange
intermediate forms of this patch, cause right now it sure doesn't seem
to be necessary. And yes, now that I think about it we certainly
can't be doing this in APR 0.9.x.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 8 16:59:50 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.