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

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

Re: [rdiff-backup-users] Resource forks HFS+


From: Daniel Hazelbaker
Subject: Re: [rdiff-backup-users] Resource forks HFS+
Date: Fri, 11 Jul 2003 18:02:53 -0700
User-agent: Microsoft-Entourage/10.1.1.2418

On 7/9/03 1:21 PM, "Ben Escoto" <address@hidden> wrote:

> Hmm, interesting.  How big to resource forks get?  Does OS X still use
> them, or is there just legacy support?

Okay, new info.  I did some tweakin'.  I still can't figure out how to read
the Iterate_fast but I "disabled" that one and made it use the old slower
one for testing.  It iterates fine but there is a problem.  Actually, two.

1) It cannot move the temp file to the "final" file location. OS X just
doesn't support it, you can cp tmpfile final/rsrc but not mv.
2) It seems to get very confused, and for good reason, trying to backup the
data, my guess is because of the temp file naming scheme (it is probably
trying to do something like final/tmpfile, which cannot be done).

How hard would it be, do you think, to put in a check in the backup/restore
schemes that would do use the ._filename scheme?

Example:
foo/testfile has a resource fork
The data of foo/testfile is backed up normally.
The iterator returns foo/testfile/rsrc
The backup loop senses this, if enabled for resource forks, and changes the
target name to foo/._testfile
foo/._testfile is backed up "normally"

During restore the opposite happens.

foo/testfile is restored
foo/._testfile is seen and target changed to foo/testfile/rsrc
foo/testfile/rsrc is returned, and ignored
foo/._testfile/rsrc is returned, and ignored

Would something like this make the most amount of sense, or is there another
method that may work better and easier?

Daniel





reply via email to

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