rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] switches for OS X


From: Ben Escoto
Subject: Re: [rdiff-backup-users] switches for OS X
Date: Fri, 14 Oct 2005 22:31:06 -0500

>>>>> Kevin Horton <address@hidden>
>>>>> wrote the following on Sun, 9 Oct 2005 13:45:13 -0400
> I just heard about rdiff-backup, and am testing version 1.0.1 on OS X  
> 10.4.2.  It looks like rdiff-backup needs to be run with two switches  
> set (--no-carbonfile --override-chars-to-quote '').  What does the -- 
> no-carbonfile switch do?  What info is missing from my backup if I  
> use this switch?

Supposedly rdiff-backup backs up Mac OS X carbonfile information.  I'm
not sure what this is, just that it seems to cause bugs :-)

Maybe someone who knows something about Mac OS could look at this code
snippet:

        def get_carbonfile(self):
                """Return resource fork data, loading from filesystem if
                necessary."""
                from Carbon.File import FSSpec
                import MacOS
                try: return self.data['cfile']
                except KeyError: pass

                try:
                        fsobj = FSSpec(self.path)
                        finderinfo = fsobj.FSpGetFInfo()
                        cfile = {'creator': finderinfo.Creator,
                                         'type': finderinfo.Type,
                                         'location': finderinfo.Location,
                                         'flags': finderinfo.Flags}
                        self.data['carbonfile'] = cfile
                        return cfile
                except MacOS.Error:
                        self.data['carbonfile'] = None 
                        return self.data['carbonfile']

What would cause a MacOS.Error?  And does it happen just on certain
strange files, or all the time?  Should I disable carbonfile support
by default, or is this an important feature?

> If I don't use the --override-chars-to-quote '' switch, the upper
> case characters in paths are replaced by ;XXX constructs, where XXX
> is the ASCII code for the character.  This then leads to an error
> with a too long file name.  I can see why this behaviour is needed,
> if backing up from other file systems to a Mac file system, due to
> the case insensitivity of the later.  But it shouldn't be needed if
> backing up from a case insensitive file system.

Well it's hard to determine if a file system is case sensitive unless
you can write to it (so right now the source isn't checked for case
sensitivity).

Maybe resource fork ability could be a good substitute for handling
the Mac OS case:  if the source and destination both support resource
forks, then disable quoting?


-- 
Ben Escoto

Attachment: pgp3WL9jGTrkz.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]