[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] HFS+ Resource Fork Patch
From: |
Ben Escoto |
Subject: |
Re: [rdiff-backup-users] HFS+ Resource Fork Patch |
Date: |
Tue, 15 Jul 2003 23:10:07 -0700 |
>>>>> "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