On Wed, Sep 18, 2002 at 05:59:58PM +0200, Pascal Bourguignon wrote:
>
> Jason Smith <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
Remember Cernan and Schmitt
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
