Re: [rdiff-backup-users] Resource Forks and metadata file

[Daniel Hazelbaker]

> The place it could matter is if these files do not have an extension.
> For instance, some program may save a PDF without a .pdf extension, and
> instead set the creator/type info.  Preview, for instance, won't open it
> if it doesn't have a .pdf or the proper creator/type.
> 
> Granted, with OS X, this is becoming less common, but it still happens.

True.  It would be a slight problem, but not one we couldn't work around. We
store everything under directory headers (i.e. Pagemaker files go under the
Pagemaker directory) so if worst came to worse we could scan the directory
and add extensions as needed.

But, as my choices are tape backup or this, I will choose this.  Tape backup
just does not work too well on the Mac yet. At least not with large volumes
like this. With how many changes we make to our files the tapes were filling
up so fast (and it was an array of 7 VXA-2 tapes) that we had to nuke the
tapes and start over every 2 weeks. Which basically put the server out of
commission for about 60 hours. Besides, with a setup like this I can run
cron jobs on the clients to backup critical data every day/night/whatever.

It may not be perfect yet, but it is extremely promising.  If I remember, I
am going to try and talk to somebody at Macworld in January about this
problem. Ask for some suggestions on writing a C-api interface (or if I feel
really challenging a Python API) that will let us "correctly" read all HFS
data, resource forks, creator/type, etc. I know how to read some of it, but
I am really not an expert on HFS+ so I don't even know all it has to be
backed up yet.

> -- John

Daniel