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
