Re: [rdiff-backup-users] HFS+ Resource Fork Patch

[Ben Escoto]

>>>>> "DH" == Daniel Hazelbaker <address@hidden>
>>>>> wrote the following on Mon, 14 Jul 2003 19:57:21 -0700

  DH> Greetings again everybody, I have compiled a patch against
  DH> 0.12.0 for supported HFS+ resource forks as metadata. (unless
  DH> somebody has a better way to store the occasional 200K+ metadata
  DH> resource fork file lines, its stored as hex at the moment).  I
  DH> have run this on a few small directories and it seems to work
  DH> fine.  Again, however, my knowledge of python is not great so
  DH> there is some cleanup that can be done and I am not sure if I
  DH> have patched all the "points of access" that I need to to make
  DH> sure resource forks are always worked with under an HFS+
  DH> environment.  If somebody could take a look at this and give me
  DH> some feedback on any changes that should be made that would be
  DH> wonderful.

  DH>     In theory (there is a great idea for programmers) this
  DH> _should_ work if the #if 1 statements in the cmodule.c file are
  DH> changed to #if 0. (like I said, this still has some cleanup to
  DH> do). But anyway, if those are changed then in theory
  DH> rdiff-backup should work like normal without resource forks.

Nice patch.  I like the idea of just including the resource fork in
each RPath/RORPath object.  That is basically how extended attributes
are treated.  It removes the complication of messing with all the ITRB
and selection stuff, which probably would have been extremely painful.
In fact, if I may ask, why did you patch selection.py at all?  It
seems the patch you posted doesn't change it at all (besides changing
the name of a variable, which was admittedly confusingly named since
'rpath' is also a module).

The main disadvantage of this method is that all the resource fork
information will be transmitted on all backups, even if the file has
not changed at all.  For this reason I think we'll move away from the
current extended attribute system and compare files by ctime.  This
will be more complicated though.

For feedback:

1.  You could have picked a more descriptive identifier than '1' in
    the C section.  :-)  Also python strings can contain arbitrary
    data, so the hex conversion may have been unnecessary?

2.  Your file does not compare the resource fork data.  If a file's
    resource fork changes but not its actual data, permissions, etc.,
    I'm not sure it will be detected.

3.  A few sections talk about index[0].  For instance:

    rp = RPath(self.conn, self.base + "/" + self.index[0], ("rsrc",));

    besides the semi-colon being unnecessary (this is in python), I
    think this will cause problems when you backup a resource fork
    that is, say, two directories down instead of being in the base
    directory.  Probably you are looking for something like

    rp = self.append('rsrc')


-- 
Ben Escoto

pgp0iDBIpjnJv.pgp
Description: PGP signature