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

Re: [BUG+PATCH] Repository "corruption" when committing several versions of a huge file

From: Branko ─îibej <brane_at_xbc.nu>
Date: Tue, 29 Nov 2011 15:48:08 +0100

On 29.11.2011 15:32, Daniel Shahaf wrote:
> On Tuesday, November 29, 2011 2:47 PM, "Martin Buck" <mb-tmp-fhoirefvba.ncnpur.bet_at_gromit.dyndns.org> wrote:
>> The problem is that subversion/libsvn_fs_fs/fs_fs.c:read_rep_line()
>> correctly parses the size of the base revision for r2 as a 64 bit number,
>> but then stores it in an apr_off_t which is 32 bits on my machine.
>>
> Why isn't apr_off_t 64 bits?

If you look at the patch, I think there's a typo there -- the size is
stored in an apr_size_t, which has 32 bits; the patch changes that to
svn_filesize_t.

-- Brane

> @@ -2575,7 +2575,7 @@
>
> svn_revnum_t base_revision;
> apr_off_t base_offset;
> - apr_size_t base_length;
> + svn_filesize_t base_length;
> I'd like both BASE_OFFSET and BASE_LENGTH to be 64 bit types. Would it
> work to make them both svn_filesize_t?

It is not correct to use svn_filesize_t as an argument to lseek.

It would be interesting to see if Subversion works on a system that
supports large files but has a 32-bit off_t, however, that doesn't
appear to be the case here.

-- Brane
Received on 2011-11-29 15:48:46 CET

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.