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

[Daniel Hazelbaker]

On 7/15/03 11:10 PM, "Ben Escoto" <address@hidden> wrote:

> 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).

Ahh, looked at the patch file, sorry that was a left-over from my initial
attempt. I had initially tried to do this in selection.py by making it yield
the /rsrc files as well as the "original", this was a dismal failure. :) And
yes, very confusing indeed. Took me a while to figure out wtheck python kept
giving me errors when I was using the exact same terminology to access RPath
as other modules ;)

> 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.

*nod* This will be a speed slow down - another reason this should be made
into an option (either at "build" time or run-time). For people like me who
are doing everything over at least 100Mb and sometimes gigabit it doens't
matter, but for people doing things across the internet or whatnot, speed
matters... The second reason this would be good as an option the data will
still be sent in the situation of a linux client without resource forks
backing up (and later restoring from) a mac server with resource forks. The
server will recognize it can do resource forks and load the fork information
to be sent across the line, even though the linux client can do nothing with
it.

> 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?

*grin* sorry, like I said it was a quick patch.  I don't know how you
configure build-time options (like this) with setup.py, so I just did #if 1
for the moment for my own testing.  The cmodule should at least be
configurable to not do resource forks, since it could wreak havoc on a non
forked FS.  Again, not sure how that would be done with setup.py?  I was
thinking for the long term something "generic" like HAS_RFORKS. As for the
hex, it needs to be hex in the metadata file at least.  Since it is a text
file I don't think it would be good to be spitting in nulls and line feed
characters as part of the resource fork.  In memory though I can probably
leave it as binary since that will cut down on transmission time by half.

> 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.

It gets compared in rpath's equal method by the "default handler":
    elif (not other.data.has_key(key) or
        self.data[key] != other.data[key]): return None

I think this should make it check if the file has changed by making sure the
resource fork data is the same. I am guessing anyway, that this method is
used as part of the comparison to make sure files have been changed before
being backed up?

On the other hand, in compare_loose I had to make it skip comparing the
resource fork because after a backup the actual file would not have a
resource fork, thus the resourcefork entry would be empty in the array
causing it to say it had not backed up properly and abort that file. Very
annoying :P.  Not sure why it doesn't use the metadata it has stored with
the file, that seems like a Bad Thing.  But that method is only used a
couple of places and from a quick look through it seemed safe to make that
change.

Hmm... On thinking of this, actually, unless it loads the metadata when it
compares a file before backing it up (which it should, am I correct?) then
__eq__ won't work either...

> 3.  A few sections talk about index[0].  For instance:
> [...]
>   rp = self.append('rsrc')

Ahh yes.. Like I said not great with Python.. That would certainly make
things easier. :>

I am going to try and get a script together that will diff both regular file
data and then diff the resource fork data so I can run this on a rather
large data repository and make sure everything is restored properly.  With
any luck that will show no differences in the data.

Daniel