some clarity Re: HFS+ resource forks: WIP patch included

[Kevin Alexander Boyd]

On Wed, 10 Mar 2004, D Andrew Reynhout wrote:

>
> On HFS+, a resource fork for <filename> is accessed via
> <filename>/..namedfork/rsrc .  Obviously, we can't send the
> same filename to the destination, because an inode can't be
> a regular file and a directory simultaneously.
>
> Map:  <filename>/..namedfork/rsrc
> to:   <filename>.~~~namedfork.rsrc
>
There are chflags and finder metadata to be mindful of as well.

On your website, you state:

"There are a few ways to approach the problem.  RsyncX and rsync_hfs
(by Kevin Boyd) turn the files into one of the single-fork formats
of olde (e.g.: macbinary, applesingle, etc) and transfer them that
way, then unwrap them on the other side.  This method requires a
HFS+ filesystem on the both sides, so it didn't suit my needs."

This is untrue. rsync_hfs does not encode or split the file at all, it
does a read in place.  rsync_hfs with the --eahfs flag requires rsync_hfs
on the other end because it has to catch all of the extra unencoded data
that it throws.

For --eahfs, what needs to be implemented is catching extra data on
non-HFS+ filesystems, say storing them in a standard Apple alien FS
format. If you change the file (encode split, etc), you are altering the
source folders, which is not desirable.  You could encode the files and
trick rsync into using applesingle files, but that would incur a space and
encode time penalty.  You could encode (or split) files into appledouble
format, which would incur less of a time and space penalty, but would
still require additional space on the source machine.

Both of these options do require a lot of 'tricking' rsync into thinking
it is processing one set of files instead of another.  I've considered
taking the penalty for appledouble, storing the created metadata resource
files in a temporary, non-source tree location (like /tmp/), given the
demand for cross-platform storage.  I'd say most people would prefer the
source to be untouched, and let the destination create the appropriate
repository for additional data (encode metadata and resource fork in
memory at source, perform rsync algo with dest, and then send what is
needed.)

The agreed (and best) thought would be for SUS accepted format EA and ACL
support in rsync, and for HFS+ patches for EA and ACL support a la:

http://acl.bestbits.at/

to support other filesystems.

Kevin Boyd
OS X Deployment Coordinator
Sys Adm UMIT Contract Services