64-bit Python
January 30, 2004 08:04AM
I run rdiff-backup on a 32-bit Linux machine (SuSE 9.0 P-II), trying to
back up a 64-bit machine (SuSE 9.0 Kernel 2.6.1 AMD64). This morning I
got the error included at the end.

As best as I can tell, what's happening is a mismatch between the 32-bit
integer types on one side and 64-bit integer type on the other side. Is
this true?

Has anyone else seen this? It seems that rdiff-backup is best run with
32-bit pythons on both sides...

-- Bob

backup:/backup # rdiff-backup --exclude /export/music
192.168.1.3::/export /backup/export
Password:
########## /export /backup/export
-----------------------------------------------------------------
Detected abilities for source (read only) file system:
Access control lists Off
Extended attributes Off
Mac OS X style resource forks Off
-----------------------------------------------------------------
-----------------------------------------------------------------
Detected abilities for destination (read/write) file system:
Characters needing quoting ''
Ownership changing On
Hard linking On
fsync() directories On
Directory inc permissions On
Access control lists Off
Extended attributes Off
Mac OS X style resource forks Off
-----------------------------------------------------------------
Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line
247, in Main
take_action(rps)
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line
218, in take_action
elif action == "backup": Backup(rps[0], rps[1])
File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line
268, in Backup
backup.Mirror(rpin, rpout)
File "/usr/lib/python2.3/site-packages/rdiff_backup/backup.py", line
38, in Mirror
DestS.patch(dest_rpath, source_diffiter)
File "/usr/lib/python2.3/site-packages/rdiff_backup/backup.py", line
215, 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
473, in fast_process
if self.patch_to_temp(rp, diff_rorp, tf):
File "/usr/lib/python2.3/site-packages/rdiff_backup/backup.py", line
499, in patch_to_temp
if new.lstat(): rpath.copy_attribs(diff_rorp, new)
File "/usr/lib/python2.3/site-packages/rdiff_backup/rpath.py", line
162, in copy_attribs
if not rpin.isdev(): rpout.setmtime(rpin.getmtime())
File "/usr/lib/python2.3/site-packages/rdiff_backup/rpath.py", line
734, in setmtime
self.conn.os.utime(self.path, (long(time.time()), modtime))
OverflowError: long int too large to convert to int
Exception exceptions.TypeError: "'NoneType' object is not callable" in
<bound method GzipFile.__del__ of <gzip open file
'/backup/export/rdiff-backup-data/file_statistics.2004-01-30T01:36:13-04:00.data.gz', mode 'wb' at 0x40676760 0x4067e60c>> ignored
Exception exceptions.TypeError: "'NoneType' object is not callable" in
<bound method GzipFile.__del__ of <gzip open file
'/backup/export/rdiff-backup-data/error_log.2004-01-30T01:36:13-04:00.data.gz', mode 'wb' at 0x4043bda0 0x4067e9ec>> ignored
Exception exceptions.TypeError: "'NoneType' object is not callable" in
<bound method GzipFile.__del__ of <gzip open file
'/backup/export/rdiff-backup-data/mirror_metadata.2004-01-30T01:36:13-04:00.snapshot.gz', mode 'wb' at 0x40676720 0x4067e54c>> ignored
Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py", line
247, in Main
take_action(rps)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py", line
216, in take_action
connection.PipeConnection(sys.stdin, sys.stdout).Server()
File "/usr/lib64/python2.3/site-packages/rdiff_backup/connection.py",
line 336, in Server
self.get_response(-1)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/connection.py",
line 298, in get_response
try: req_num, object = self._get()
File "/usr/lib64/python2.3/site-packages/rdiff_backup/connection.py",
line 221, in _get
raise ConnectionReadError("Truncated header string (problem "
rdiff_backup.connection.ConnectionReadError: Truncated header string
(problem probably originated remotely)
backup:/backup #
64-bit Python
January 30, 2004 01:30PM
On 2004-01-30, Bob Fischer <bob.fischer17 < at > earthlink.net> wrote:
[quote]As best as I can tell, what's happening is a mismatch between the 32-bit
integer types on one side and 64-bit integer type on the other side. Is
this true?
[/quote]
I back up my 64-bit Alpha to a 32-bit PC regularly, and haven't seen any
particular issues with that arrangement. But I don't know if that holds
true in other situations. I've never really seen any problems porting
Python programs to Alpha.

-- John
64-bit Python
January 31, 2004 02:45PM
[quote][quote][quote][quote][quote]Bob Fischer <bob.fischer17 < at > earthlink.net>
wrote the following on Fri, 30 Jan 2004 10:56:57 -0500
[/quote][/quote][/quote][/quote]I run rdiff-backup on a 32-bit Linux machine (SuSE 9.0 P-II), trying to
back up a 64-bit machine (SuSE 9.0 Kernel 2.6.1 AMD64). This morning I
got the error included at the end.

As best as I can tell, what's happening is a mismatch between the 32-bit
integer types on one side and 64-bit integer type on the other side. Is
this true?

Has anyone else seen this? It seems that rdiff-backup is best run with
32-bit pythons on both sides...
[/quote]...
[quote]self.conn.os.utime(self.path, (long(time.time()), modtime))
OverflowError: long int too large to convert to int
[/quote]
Sorry, I'm at a bit of a loss how the line:

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

can cause that error, since nothing is getting converted to an int.
Maybe there is a bug in python on one connection you are running? Try
making a temp file 'foobar', and then running python and typing in:

~ $ python
Python 2.2.3 (#1, Oct 15 2003, 23:33:35)
[GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
[quote][quote][quote]import os, time
os.utime('foobar', (long(time.time()), long(time.time())))

[/quote][/quote][/quote]
and make sure that works with no errors. (Try this on both sides.)

--
Ben Escoto
64-bit Python
January 31, 2004 03:26PM
On Sat, Jan 31, 2004 at 02:44:15PM -0800, Ben Escoto wrote:
[quote]Sorry, I'm at a bit of a loss how the line:

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

can cause that error, since nothing is getting converted to an int.
[/quote]
Sure something is; os.utime is calling utime(2), which wants time_t's,
which are really ints. So os.utime is extracting ints somewhere.

Of course, this shouldn't be a problem unless time.time() is reporting
a date in 2038 or later, so I don't quite get what's going wrong...

-- Nathaniel

--
Damn the Solar System. Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
-- Lord Jeffrey
Sorry, only registered users may post in this forum.

Click here to login