Ronald Taneza wrote:
> Hi Julian,
>
> Thank you for your quick response and patch. I hope that this is fixed
> in the next 1.8.x release and that CollabNet will also release an update
> to Subversion Edge.
It should be.
> I'm still not so clear how this is exactly a problem with svnrdump
> 1.8.19 (from Subversion Edge). This is my first time browsing through
> the svn source code, and I hope you'll indulge me with my questions below.
>
> We are using Subversion Edge 5.2.2 (Windows 64-bit) on a Windows Server
> 2012 (64-bit) OS.
This bug occurred because the "%ld" format and/or the 'long' data type
were 32-bit. This is indeed the case:
On 64-bit Windows, 'long' is a 32-bit type (and 'long long' is 64-bit;
on most other platforms both are 64-bit.)
(
https://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows#384672
)
> I also verified that the httpd.exe, svn.exe, and svnrdump.exe binaries
> are 64-bit. (I ran the "file xxx" command in Cygwin and also checked
> their PE signatures as described here:
> https://superuser.com/questions/358434/how-to-check-if-a-binary-is-32-or-64-bit-on-windows).
>
> You mentioned:
>
> > SVN_ERR(svn_stream_printf(eb->stream, pool,
> SVN_REPOS_DUMPFILE_CONTENT_LENGTH
> ": %ld\n\n",
> (unsigned long)info->size +
> propstring->len));
>
> > info->size is apr_off_t ... probably 64 bits on most systems.
> > propstring->len is apr_size_t ... probably 64 bits on most systems.
I was wrong about that: apr_size_t would be 32-bit on 32-bit
architectures. File sizes (apr_off_t) are more likely to be 64-bit,
although there may be some platforms where they are 32-bit, maybe
depending on compile-time options or something that is configurable.
Therefore my initial patch (changing to use APR_SIZE_T_FMT) was wrong
(would not have worked on 32-bit architectures). I have now corrected
that to use APR_OFF_T_FMT.
> > 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.
When I wrote that, I was assuming a 32-bit architecture.
> On a 64-bit system where unsigned long is uint64:
On a standard Windows-64 system, it's not.
I hope that clears up the issue.
- Julian
Received on 2017-11-23 12:17:21 CET