Backup Central

Hello all,

When I try to backup a 12G of data (multiple directories, multiple files in
size ranging from 0 bytes to roughly 700 MB) I get the following error:

^[[ATraceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib64/python2.4/site-packages/rdiff_backup/Main.py", line 280, in
Main
take_action(rps)
File "/usr/lib64/python2.4/site-packages/rdiff_backup/Main.py", line 250, in
take_action
elif action == "backup": Backup(rps[0], rps[1])
File "/usr/lib64/python2.4/site-packages/rdiff_backup/Main.py", line 303, in
Backup
backup.Mirror(rpin, rpout)
File "/usr/lib64/python2.4/site-packages/rdiff_backup/backup.py", line 38,
in Mirror
DestS.patch(dest_rpath, source_diffiter)
File "/usr/lib64/python2.4/site-packages/rdiff_backup/connection.py", line
445, in __call__
return apply(self.connection.reval, (self.name,) + args)
File "/usr/lib64/python2.4/site-packages/rdiff_backup/connection.py", line
367, in reval
if isinstance(result, Exception): raise result
OverflowError: long int too large to convert to int

This happens in the initial backup.
Any idea what is happening, and how to fix this? I backup from an amd64 to a
x86
Information
librsync 0.9.7
rdiff-backup 0.13.6
python 2.4.1
When I backup a smaller partition, everything works well

Jan Jitse

the error in this case is generated on the remote side and raised back on
the local side... for more help try -v5 which will let us see the error on
the remote side before it's sent back. that might help narrow it some.

but my guess is it's a uid/gid issue -- there's a commit in CVS 0.13.7
which might help this... you could try the current cvs
<https://savannah.nongnu.org/cvs/?group=rdiff-backup>.

-dean

On Saturday 02 July 2005 03:28, dean gaudet wrote:
the error in this case is generated on the remote side and raised back on
the local side... for more help try -v5 which will let us see the error on
the remote side before it's sent back. that might help narrow it some.

but my guess is it's a uid/gid issue -- there's a commit in CVS 0.13.7
which might help this... you could try the current cvs
<https://savannah.nongnu.org/cvs/?group=rdiff-backup>.

-dean
I took a CVS snapshot of today (02/07/2005) and made it run with -v5. The
error:

---------------------------------------------------------------------------------------------------
Sending back exception long int too large to convert to int of type
exceptions.OverflowError:

File "/usr/lib/python2.3/site-packages/rdiff_backup/connection.py", line
334,
in answer_request
result = apply(eval(request.function_string), argument_list)
File "/usr/lib/python2.3/site-packages/rdiff_backup/backup.py", line 218, in
patch
ITR(diff.index, diff)
File "/usr/lib/python2.3/site-packages/rdiff_backup/rorpiter.py", line 279,
in
__call__
last_branch.fast_process(*args)
File "/usr/lib/python2.3/site-packages/rdiff_backup/backup.py", line 476, in
fast_process
if self.patch_to_temp(rp, diff_rorp, tf):
File "/usr/lib/python2.3/site-packages/rdiff_backup/backup.py", line 503, in
patch_to_temp
rpath.copy_attribs(diff_rorp, new)
File "/usr/lib/python2.3/site-packages/rdiff_backup/rpath.py", line 164, in
copy_attribs
if not rpin.isdev(): rpout.setmtime(rpin.getmtime())
File "/usr/lib/python2.3/site-packages/rdiff_backup/rpath.py", line 765, in
setmtime
self.conn.os.utime(self.path, (long(time.time()), modtime))

Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib64/python2.4/site-packages/rdiff_backup/Main.py", line 280, in
Main
take_action(rps)
File "/usr/lib64/python2.4/site-packages/rdiff_backup/Main.py", line 250, in
take_action
elif action == "backup": Backup(rps[0], rps[1])
File "/usr/lib64/python2.4/site-packages/rdiff_backup/Main.py", line 303, in
Backup
backup.Mirror(rpin, rpout)
File "/usr/lib64/python2.4/site-packages/rdiff_backup/backup.py", line 38,
in
Mirror
DestS.patch(dest_rpath, source_diffiter)
File "/usr/lib64/python2.4/site-packages/rdiff_backup/connection.py", line
445
, in __call__
return apply(self.connection.reval, (self.name,) + args)
File "/usr/lib64/python2.4/site-packages/rdiff_backup/connection.py", line
367
, in reval
if isinstance(result, Exception): raise result
OverflowError: long int too large to convert to int
Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
localhost rdiff-backup # rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 280, in
Main
take_action(rps)
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 248, in
take_action
connection.PipeConnection(sys.stdin, sys.stdout).Server()
File "/usr/lib/python2.3/site-packages/rdiff_backup/connection.py", line
352,
in Server
self.get_response(-1)
File "/usr/lib/python2.3/site-packages/rdiff_backup/connection.py", line
314,
in get_response
try: req_num, object = self._get()
File "/usr/lib/python2.3/site-packages/rdiff_backup/connection.py", line
230,
in _get
raise ConnectionReadError("Truncated header string (problem "
rdiff_backup.connection.ConnectionReadError: Truncated header string (problem
probably originated remotely)
Exception exceptions.TypeError: "'NoneType' object is not callable"
in /usr/lib/
python2.3/gzip.py:129: FutureWarning: hex()/oct() of negative int will return
a
signed string in Python 2.4 and up
return '<gzip ' + s[1:-1] + ' ' + hex(id(self)) + '>'
<bound method GzipFile.__del__ of <gzip open file
'/mnt/huge/backup/rdiff/rdiff-
backup-data/file_statistics.2005-07-02T13:24:43+02:00.data.gz', mode 'wb' at
0xb
7ec8ba0 0xb7d795ec>> ignored
Exception exceptions.TypeError: "'NoneType' object is not callable" in <bound
me
thod GzipFile.__del__ of <gzip open file
'/mnt/huge/backup/rdiff/rdiff-backup-da
ta/error_log.2005-07-02T13:24:43+02:00.data.gz', mode 'wb' at 0xb7ec8b60
0xb7ee3
dcc>> ignored
Exception exceptions.TypeError: "'NoneType' object is not callable" in
ignored

---------------------------------------------------------------------------------------------------
So, it is not fixed with recent CVS. Also, no files larger than 600 MB were
involved. There are around 40000 files in the partition. Hopefully, this more
informative error will show the way to a solution.

Jan Jitse

On Saturday 02 July 2005 15:24, Jan Jitse Venselaar wrote:
On Saturday 02 July 2005 03:28, dean gaudet wrote:
the error in this case is generated on the remote side and raised back on
the local side... for more help try -v5 which will let us see the error
on the remote side before it's sent back. that might help narrow it
some.

but my guess is it's a uid/gid issue -- there's a commit in CVS 0.13.7
which might help this... you could try the current cvs
<https://savannah.nongnu.org/cvs/?group=rdiff-backup>.

-dean

I took a CVS snapshot of today (02/07/2005) and made it run with -v5. The
error:


For your info, I tried backing up via NFS, instead of SSH, so from 64-bit ->
64-bit, and no error occurs.

Jan Jitse
sleeping better, now backing up works again.

On Sat, 2 Jul 2005, Jan Jitse Venselaar wrote:

self.conn.os.utime(self.path, (long(time.time()), modtime))

aha... that's probably a 64-bit time_t being stuffed into a 32-bit
time_t... it should be easy enough to fix, but there should probably be a
warning because the fix would involve truncating the time.

oh you've probably got a file with a timestamp far in the future.

-dean

On Saturday 02 July 2005 23:35, you wrote:
On Sat, 2 Jul 2005, Jan Jitse Venselaar wrote:
self.conn.os.utime(self.path, (long(time.time()), modtime))

aha... that's probably a 64-bit time_t being stuffed into a 32-bit
time_t... it should be easy enough to fix, but there should probably be a
warning because the fix would involve truncating the time.

oh you've probably got a file with a timestamp far in the future.

-dean
That was it yes. Got a file from 2059....
32-bit time can't handle that :)

Many thanks,

Jan Jitse