> *From:* Ronald Taneza [mailto:ronald.taneza_at_gmail.com]
> *Sent:* dinsdag 21 november 2017 15:44
> *To:* users_at_subversion.apache.org
> I got the error below while running "svnadmin load -M 0" to load a dump
> file created by "svnrdump dump".
> svnadmin: E140001: Sum of subblock sizes larger than total block
> content length
> This error was reported when "svnadmin load" was loading a big file
> (around 2 GB) from a revision in the dump file.
> Checking the dump file produced by svnrdump (svn version 1.8.19), I
> noticed that the Content-length for the 2GB file is a negative value!
> SVN-fs-dump-format-version: 3
> Node-path: TheBigFile
> Node-kind: file
> Node-action: add
> Prop-delta: true
> Prop-content-length: 59
> Text-delta: true
> Text-content-length: 2238208329
> Text-content-md5: d2f79377abb0db99b37460c8156727fb
> Content-length: -2056758908
Thank you for finding this!
I can see this bug existed in svnrdump up to 1.8.19. (For 1.9 I refactored this to use common code shared with 'svnadmin dump' which does not have this bug.)
In 1.8.19, subversion/svnrdump/svnrdump.c:close_file() contains:
(unsigned long)info->size +
else if (fb->dump_text)
info->size is apr_off_t ... probably 64 bits on most systems.
propstring->len is apr_size_t ... probably 64 bits on most systems.
It uses "%lu" for the text content, which thus work OK up to 4 GB, and "%ld" for the overall content length which thus only works up to 2 GB.
Earlier in this file, the property content length is printed correctly:
buf = apr_psprintf(pool, SVN_REPOS_DUMPFILE_CONTENT_LENGTH
": %" APR_SIZE_T_FMT "\n", len);
The attached patch should fix it; not yet tested.
Received on 2017-11-22 15:36:20 CET