Feature request: Sync Mac OS resource forks and metadata on Mac OS X

[jw schultz]

On Wed, Sep 18, 2002 at 05:59:58PM +0200, Pascal Bourguignon wrote:
> 
> Jason Smith <smithja at cs.unc.edu> wrote:
> > > Mac OS X provides support for the Mac file system resource forks and 
> > > mac specific metadata (e.g., creator and file type). Most Unix 
> > > applications ignore this information, but it is accessible. It would 
> > > be great if rsync between two Mac OS X machines could sync this 
> > > information as well as the usual Unix file contents and unix metadata.
> > 
> > 	It's already done: http://www.macosxlabs.org/rsyncx/rsyncx.html
> > 
> > 	The underlying CLI tool is an HFS+ resource aware version of rsync 
> > 2.5.5.
> > 
> > 	I've asked this before on this list, and never received a response... 
> > what are the barriers to getting this support added to the main rsync 
> > tree as part of the MacOS X configuration?  Having this in the maintree 
> > would be highly useful to MacOS X users, instead of having to have to 
> > continually patch the rsync tree with the HFS+ patch.
> 
> Linux too supports  HFS with data forks and  resource forks and Finder
> infos.  And three different ways at that.
> 
> Try either: mount -t hfs -o 'fork=cap'      ...
>             mount -t hfs -o 'fork=double'   ...
>         or  mount -t hfs -o 'fork=netatalk' ...
> 
> Check '/usr/src/linux/fs/hfs/HFS.txt'.
> 
> Well, actually, what's in as  support is just some convention, used by
> various user-level software, about the  naming of files and storage of
> forks  on  a unix  file  system.   See  for example  mkisofs(8)  which
> supports the following conventions:
> 
>        CAP AUFS format
>        AppleDouble/Netatalk
>        AppleSingle
>        Helios EtherShare
>        IPT UShare
>        MacBinary                            
>        Apple PC Exchange
>        SGI/XINET                            
>        Thursby Software Systems DAVE        
>        Services for Macintosh               (NT Servers)
> 
> What's remarkable is that these convention are used on a full range of
> systems where rsync can run.
> 
> 
> So, I  would suggest that  rsync (main distribution) supports  them as
> well and that  it uses the "local" convetion at each  end of the pipe.
> 
> 
> So,  if  rsync'ing  a volume  where  HFS  forks  are stored  with  the
> "Services  for Macintosh"  convetion of  the NT  servers, to  a volume
> where HFS  forks are stored in  the MacBinary convention,  that such a
> transformation be  done.  Most often  it'll just mean change  the file
> name,  but  it  can also  mean  mixing  some  forks  into one  or  two
> files. (AppleDouble stores the data fork in one file, and the resource
> fork  and  Finder  info   into  another  (hence  double  file),  while
> AppleSingle stores  everything into one  file, but CAP stores  each in
> its own file (3 in total)).

The lack of standards here makes things very awkward.
Almost all of these methods are the prodcts of application
level code.  Deciding which to support has nothing to do
with 'native' capabilities.  The thing that really must be
avoided is trying to support all of them or worse supporting
more than one at a time.  Further some of these would be
poor choices simply because we would be inheriting filename
problems.

If done i would say that there are two or perhaps three that
make some sense.  My criteria is based on two primary
factors:  What is really native to the 'local' platform and
what will be compatible with network access by a Mac.

On windows i'd say support for the 'Services for Macintosh'
scheme is the one to go with.  It appears to be blessed by
MS and rsync would be compatible with network access.

For UNIX/Linux i lean toward 'MacOS X AppleDouble' because
it is blessed by Apple and rsync would be compatible with
network access at least for OS-X clients running NFS.

The third scheme that makes sense would be compatibility
with the Mac SMB clients.  I don't know if 'DAVE' is the
only way or if Apple provided another client that does this.

As for the kernel based 'native' forms, i don't really think
they count all that much for this.  They exist to allow the
native OS to mount and access media with HFS.  Accordingly
the purpose of these is at a tangent from the purpose of
rsync.  Further while SGI/XINET is probably not amenable to
change the Linux HFS filesystem module is still young and 
doesn't seem to be locked into just one way.

I'd rather see generalized support for extended attributes
than just support for HFS.  The most important thing decide
here is not how we store the data on disk but how we
represent it in the rsync protocol.  An rsync protocol that
supports extended attributes (includeing ACLs) would be able
to support the HFS finder and resource forks.

As much as i dislike the idea of supporting multiple formats
it might be necessary.  I would however caution against
adding to their number or even trying to implement more than
the bare minimum.  The best bet would probably be to create
them as patches and add them to mainline only when a given
format has sufficient critical mass.  Were the project
younger i would suggest they be .so modules.

For storage of this data on un-supporting filesystems we
should probably look at having one option that specifes the
auxiliarry file names and formats.  Something like --eamap.
Where the option would accept a format name.  So you might
have '--eamap dave' or '--eamap OSX'.  Whatever is done only
one should be supported at a time.

The other question is what to do about filesystems that may
provide partial support.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt