SearchFAQMemberlist Log in
Reply to topic Page 1 of 1
TypeError: unsubscriptable object (cfile[creator])
Author Message
Post TypeError: unsubscriptable object (cfile[creator]) 
On 16 Oct 2005, at 08:45, Kevin Horton wrote:

On 15 Oct 2005, at 22:49, Ben Escoto wrote:


Kevin Horton <khorton01 < at > rogers.com>
wrote the following on Fri, 14 Oct 2005 23:16:18 -0400



It seems that with OS X 10.4 you need to use two switches:

--no-carbonfile --override-chars-to-quote ''

The second switch ends with two single quote characters. It might
only be necessary if you are backing up to and from the native HFS+
file system.



What if you add this patch:

--- rpath.py 2005-09-07 12:04:37.000000000 -0500
+++ rpath.py.new 2005-10-15 21:48:04.000000000 -0500
< at > < at > -1150,6 +1150,7 < at > < at >

def write_carbonfile(self, cfile):
"""Write new carbon data to self."""
+ if not cfile: return
log.Log("Writing carbon data to %s" %
(self.index,), 7)
from Carbon.File import FSSpec
import MacOS

Do you still need to add --no-carbonfile, or does that fix that
problem?


This patch seems to stop the crash. I did an incremental backup,
and now I get a bunch of UpdateErrors like this:

UpdateError Desktop/RV_Stuff/POH archive/graphs/all-3.gp Updated
mirror temp file /Volumes/Ext_BU/Users/kwh/rdiffbu/Desktop/RV_Stuff/
POH archive/graphs/rdiff-backup.tmp.7305 does not match source

The file listed in the first of these UpdateErrors was the one that
was causing the crash before I started using the --no-carbonfile
flag. I assume the backed up file would have included the
carbonfile data if that flag had not been used, and this is why
rdiff-backup is now complaining about the file not matching the
source. Does this make sense?


I shouldn't have been so quick to send that last message. rdiff-
backup churned away for almost three hours working on an incremental
backup (normally it takes about 30 minutes), then failed with:

Traceback (most recent call last):
File "/sw/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File "/sw/lib/python2.4/site-packages/rdiff_backup/Main.py", line
283, in Main
take_action(rps)
File "/sw/lib/python2.4/site-packages/rdiff_backup/Main.py", line
253, in take_action
elif action == "backup": Backup(rps[0], rps[1])
File "/sw/lib/python2.4/site-packages/rdiff_backup/Main.py", line
303, in Backup
backup.Mirror_and_increment(rpin, rpout, incdir)
File "/sw/lib/python2.4/site-packages/rdiff_backup/backup.py",
line 51, in Mirror_and_increment
DestS.patch_and_increment(dest_rpath, source_diffiter, inc_rpath)
File "/sw/lib/python2.4/site-packages/rdiff_backup/backup.py",
line 227, in patch_and_increment
for diff in rorpiter.FillInIter(source_diffiter, dest_rpath):
File "/sw/lib/python2.4/site-packages/rdiff_backup/rorpiter.py",
line 181, in FillInIter
for rp in rpiter:
File "/sw/lib/python2.4/site-packages/rdiff_backup/backup.py",
line 103, in get_diffs
for dest_sig in dest_sigiter:
File "/sw/lib/python2.4/site-packages/rdiff_backup/backup.py",
line 167, in get_sigs
for src_rorp, dest_rorp in cls.CCPP:
File "/sw/lib/python2.4/site-packages/rdiff_backup/backup.py",
line 301, in next
source_rorp, dest_rorp = self.iter.next()
File "/sw/lib/python2.4/site-packages/rdiff_backup/rorpiter.py",
line 100, in Collate2Iters
try: relem2 = riter2.next()
File "/sw/lib/python2.4/site-packages/rdiff_backup/metadata.py",
line 257, in iterate
try: yield self.record_to_object(self.buf[:next_pos])
File "/sw/lib/python2.4/site-packages/rdiff_backup/metadata.py",
line 165, in Record2RORP
else: data_dict['resourcefork'] = binascii.unhexlify(data)
TypeError: Non-hexadecimal digit found
Exception exceptions.TypeError: "'NoneType' object is not callable"
in <bound method GzipFile.__del__ of <gzip open file '/Volumes/Ext_BU/
Users/kwh/rdiffbu/rdiff-backup-data/file_statistics.
2005-10-16T07:38:50-04:00.data.gz', mode 'wb' at 0x374de8 0x7a3120>>
ignored
Exception exceptions.TypeError: "'NoneType' object is not callable"
in <bound method GzipFile.__del__ of <gzip open file '/Volumes/Ext_BU/
Users/kwh/rdiffbu/rdiff-backup-data/error_log.
2005-10-16T07:38:50-04:00.data.gz', mode 'wb' at 0x79c0b0 0x7a7e18>>
ignored
Exception exceptions.TypeError: "'NoneType' object is not callable"
in <bound method GzipFile.__del__ of <gzip open file '/Volumes/Ext_BU/
Users/kwh/rdiffbu/rdiff-backup-data/mirror_metadata.
2005-10-16T07:38:50-04:00.snapshot.gz', mode 'wb' at 0x79c0f8
0x7a3da0>> ignored



Kevin Horton
Ottawa, Canada

Post TypeError: unsubscriptable object (cfile[creator]) 
Kevin Horton <khorton01 < at > rogers.com>
wrote the following on Sun, 16 Oct 2005 08:45:06 -0400

This patch seems to stop the crash. I did an incremental backup, and
now I get a bunch of UpdateErrors like this:

UpdateError Desktop/RV_Stuff/POH archive/graphs/all-3.gp Updated
mirror temp file /Volumes/Ext_BU/Users/kwh/rdiffbu/Desktop/RV_Stuff/
POH archive/graphs/rdiff-backup.tmp.7305 does not match source

The file listed in the first of these UpdateErrors was the one that
was causing the crash before I started using the --no-carbonfile
flag. I assume the backed up file would have included the
carbonfile data if that flag had not been used, and this is why
rdiff-backup is now complaining about the file not matching the
source. Does this make sense?

Yes, the problem was rdiff-backup was getting filesystem errors trying
to read the carbonfile data. Without the patch this would have
crashed rdiff-backup; with the patch rdiff-backup just skips the file
that raised the error.

So, now that we know which files are causing errors, maybe you have an
opinion on which option would be better. Here are two things I can do
despite not having any knowledge of Mac OS:

1) Apply (variant of) that patch. Files that cause carbonfile errors
would just never get backed up.

2) Apply patch, and by default turn carbonfile off. rdiff-backup
would just ignore carbonfile information so there would be no
carbonfile errors. If run with the --enable-carbonfile switch it
would act like 1).


--
Ben Escoto

Post TypeError: unsubscriptable object (cfile[creator]) 
On 16 Oct 2005, at 13:01, Ben Escoto wrote:

Kevin Horton <khorton01 < at > rogers.com>
wrote the following on Sun, 16 Oct 2005 08:45:06 -0400


This patch seems to stop the crash. I did an incremental backup, and
now I get a bunch of UpdateErrors like this:

UpdateError Desktop/RV_Stuff/POH archive/graphs/all-3.gp Updated
mirror temp file /Volumes/Ext_BU/Users/kwh/rdiffbu/Desktop/RV_Stuff/
POH archive/graphs/rdiff-backup.tmp.7305 does not match source

The file listed in the first of these UpdateErrors was the one that
was causing the crash before I started using the --no-carbonfile
flag. I assume the backed up file would have included the
carbonfile data if that flag had not been used, and this is why
rdiff-backup is now complaining about the file not matching the
source. Does this make sense?


Yes, the problem was rdiff-backup was getting filesystem errors trying
to read the carbonfile data. Without the patch this would have
crashed rdiff-backup; with the patch rdiff-backup just skips the file
that raised the error.

So, now that we know which files are causing errors, maybe you have an
opinion on which option would be better. Here are two things I can do
despite not having any knowledge of Mac OS:

1) Apply (variant of) that patch. Files that cause carbonfile errors
would just never get backed up.

2) Apply patch, and by default turn carbonfile off. rdiff-backup
would just ignore carbonfile information so there would be no
carbonfile errors. If run with the --enable-carbonfile switch it
would act like 1).

It seems that at the moment we have a choice of backing up those
files, but without the carbonfile information, or not backing up the
files at all. I believe the default should be to back up the files,
but ignore the carbonfile information - i.e. your option 2. In my
case, these files are completely useable without the carbonfile
information.

I also believe it is extremely important for users to be aware of
which files are not being backed up. If this patch is added to rdiff-
backup, it would be important to have rdiff-backup report the files
that are not being backed up so the user can determine whether to
accept that, or to back them up via some other tool. Users who
assume that every file is being backed up and then have to do a
restore will be very upset if they discover that important files are
missing.

Kevin Horton
Ottawa, Canada

Display posts from previous:
Reply to topic Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
  


Magic SEO URL for phpBB