Joe Orton wrote:
>On Thu, May 13, 2004 at 02:44:07AM +0100, Branko ÄŒibej wrote:
>
>
>>rbraswell@connected.com wrote:
>>
>>
>>
>>>Hi,
>>>I am running SVN1.0.2 on RH9 with Apache 2.0.48
>>>
>>>[svn@svn reposdump]$ svnadmin hotcopy --clean-logs /home/svn/repos
>>>/reposdump/repos-5058-hotcopy
>>>svn: Can't copy '/home/svn/repos/db/strings' to
>>>'/reposdump/repos-5058-hotcopy/db/strings.tmp': File too large
>>>
>>>This is a very big problem. Any help is greatly appreciated.
>>>
>>>
>>>
>>This is actually an APR problem -- APR was not compiled with large file
>>support. Your apr/apache/subversion package maintaniner should fix this.
>>
>>
>
>With what "fix"? Using -D_FILE_OFFET_BITS=64? This creates APR
>libraries with a non-default ABI but the default soname. That is a
>shooting offence for a package maintainer.
>
>I said it last week, and I'll say it this week, and it'll still be true
>next week too :) APR 0.9 does not support >2gb files on platforms with a
>32-bit off_t.
>
>
Which means that Subversion doesn't support hot backups of >2GB
repositories on such platforms until the day when Apache ships with
apr-1.0. And the only workaround is to ressurect (and fix) the
hot-backup.py implementation that used the BDB tools instead of calling
svnadmin hotcopy.
Or, of course, the package maintainer could produce a largefile-enabled
version of apr/httpd/etc. with a different soname, or you could compile
svnadmin with --enable-all-static and largefile support enabled.
Lots of possible fixes. I do insist that fixing this is the package
maintainer's responsibility.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 13 20:10:52 2004