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

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