On 2/8/06, Joe Orton <[EMAIL PROTECTED]> 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... -garrett
