Hi.
Several months ago, I posted my first pass at a patch to transfer
Mac OS X HFS+ metadata (resource forks and Finder metadata) to
non-HFS+ filesystems (Linux, Solaris, etc).
I finally got a chance to update the patch to reflect suggestions
offered on the list. Thanks for the ideas, this version should be
a big improvement.
The diff and a binary (and a fuller explanation) can be found at:
http://www.quesera.com/~reynhout/misc/rsync-hfsmode-patch
The current patch is against rsync-2.6.2. It still works with the
standard build of rsync on the receiving side, so only the sender
needs to be patched.
For a single HFS+ file, there will be between one and three files
transferred to the destination filesystem:
- <filename>: The regular file (data fork)
- ._<filename>: The resource fork of <filename>, iff non-empty.
- ._<filename>_metadata: Type and Creator and Finder flags
for <filename>, iff non-null.
Any suggestions on a naming scheme for the metadata file that
would minimize the risk of collisions?
Any feedback would be appreciated.
Thanks,
Andrew
reynhout@quesera.com
Here's another method for HFS+ rsyncs to non-HFS+ filesystems - the files can be synced and restored without using RsyncX: http://xnews.soad.umich.edu/RsyncX_Forums/index.php?topic=33.0 There have been varying degrees of happiness with this method. It's not perfect, just another alternative method. Kevin Boyd OS X Deployment Coordinator Sys Adm UMIT Contract Services On Mon, 16 Aug 2004, D Andrew Reynhout wrote:> Date: Mon, 16 Aug 2004 00:49:17 -0400 > From: D Andrew Reynhout <reynhout@quesera.com> > To: rsync@lists.samba.org > Subject: Mac OS X HFS+ metadata patch, take 2 > > > Hi. > > Several months ago, I posted my first pass at a patch to transfer > Mac OS X HFS+ metadata (resource forks and Finder metadata) to > non-HFS+ filesystems (Linux, Solaris, etc). > > I finally got a chance to update the patch to reflect suggestions > offered on the list. Thanks for the ideas, this version should be > a big improvement. > > The diff and a binary (and a fuller explanation) can be found at: > http://www.quesera.com/~reynhout/misc/rsync-hfsmode-patch > > The current patch is against rsync-2.6.2. It still works with the > standard build of rsync on the receiving side, so only the sender > needs to be patched. > > For a single HFS+ file, there will be between one and three files > transferred to the destination filesystem: > > - <filename>: The regular file (data fork) > - ._<filename>: The resource fork of <filename>, iff non-empty. > - ._<filename>_metadata: Type and Creator and Finder flags > for <filename>, iff non-null. > > Any suggestions on a naming scheme for the metadata file that > would minimize the risk of collisions? > > Any feedback would be appreciated. > > Thanks, > Andrew > reynhout@quesera.com > > > -- > To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync > Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html >
D Andrew Reynhout wrote:>Several months ago, I posted my first pass at a patch to transfer >Mac OS X HFS+ metadata (resource forks and Finder metadata) to >non-HFS+ filesystems (Linux, Solaris, etc). >Here's a different take, one that's been causing me problems all over, and I can't figure out if it's rsync, or samba, or some other force causing the problems. First, the setup: The bulk of the company works on Win32 machines, except our digital department, who are all using Macs. Therefor, we have a few large Win2K servers who act as file servers on the network for anyone to use. This works well; the folks on Win32 machines can see/use them and the folks in Digi can also see/use them. Those guys use both OS 9 as well as OS X machines. Here's what I want to do: they purchased a new Win2K server and loaded it up with large drives, to be used as backups for the other servers around the building. Basically what they want is a (semi) mirror copy of what the other servers hold, in case of a server failure, so they can simply re-map their share to the backup server and continue working while I fix the failed one (the data would be no more than 48 hours old since backups would only run either every night or every other night.) Sounds simple enough, right? So, here's what I thought of doing: take a free linux box I had sitting in a closet, and use it to act as a sort of backup manager. Let's assume we have Server-A with Drive1 and Drive2 on it. Now we have BackupServer with Drive1 and Drive2 on it. On the linux box, I do an smbmount to get Server-A:Drive1 mounted, and the same for BackupServer:Drive1. Then I run rsync on those drives. And this is where the problems start. I posted this message to the Samba-Tech list as well, so I'm just going to quote the archived version here: http://lists.samba.org/archive/samba-technical/2004-August/036630.html I'd like to think it's samba not being able to read those files, but from what I read here today, it seems maybe rsync is also having problems. So I'm fishing for possible ideas here. Now, I will also admit, this may not be the ideal setup. Perhaps I should just stick to xcopy on the backup server and let it do it's thing. I don't know. What I DO know is that we want to stay as far away as we can from having to buy some expensive, network backup software. We've had our share of bad luck with them (they don't always grab everything, which has come back and bit us hard in the past.) If anyone has any brilliant ideas, I'm all ears. -- W | I haven't lost my mind; it's backed up on tape somewhere. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:ashley@pcraft.com> . 303.442.6410 x130 IT Director / SysAdmin / WebSmith . 800.441.3873 x130 Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave. #6 http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
On Mon, Aug 16, 2004 at 12:49:17AM -0400, D Andrew Reynhout wrote:> The diff and a binary (and a fuller explanation) can be found at: > http://www.quesera.com/~reynhout/misc/rsync-hfsmode-patchPlease don't use -b when creating a diff -- it makes a patch that does not recreate the modified source. I'd be glad to put this into the patches dir for the next release, but it will need to be updated to apply to 2.6.3pre1 first. ..wayne..
D Andrew Reynhout wrote:> The diff and a binary (and a fuller explanation) can be found at: > http://www.quesera.com/~reynhout/misc/rsync-hfsmode-patchThis is excellent! It should vastly speed up our Linux to Mac rsync transfers over any of the other available alternatives. Two questions: Do you have to have rsync-hfsmode on both the sending and receiving machines, or will rsync-hfsmode work properly with a standard rsync install in one direction or the other? Is there any chance of this being folded into the standard rsync CVS? Greg
On Mon, 16 Aug 2004, D Andrew Reynhout wrote:> Several months ago, I posted my first pass at a patch to transfer > Mac OS X HFS+ metadata (resource forks and Finder metadata) to > non-HFS+ filesystems (Linux, Solaris, etc). > > I finally got a chance to update the patch to reflect suggestions > offered on the list. Thanks for the ideas, this version should be > a big improvement. > > The diff and a binary (and a fuller explanation) can be found at: > http://www.quesera.com/~reynhout/misc/rsync-hfsmode-patch > > The current patch is against rsync-2.6.2. It still works with the > standard build of rsync on the receiving side, so only the sender > needs to be patched. > > For a single HFS+ file, there will be between one and three files > transferred to the destination filesystem: > > - <filename>: The regular file (data fork) > - ._<filename>: The resource fork of <filename>, iff non-empty. > - ._<filename>_metadata: Type and Creator and Finder flags > for <filename>, iff non-null. > > Any suggestions on a naming scheme for the metadata file that > would minimize the risk of collisions?Any reason this couldn't use the same convention that Apple uses on UFS partitions? That is, files are stored using AppleDouble format, with the resource fork and metadata in a separate file with "._" prepended to the filename. There is no need for a "_metadata" file as the type, creator, etc. are stored along with the resource fork. If rsync could be made aware of this format, it would allow transfers to and from Apple UFS partitions (as well as remote systems) in a way compatible with Finder and other utilities such as ditto. For more on AppleDouble format, see: http://www.lazerware.com/formats/ -- In the Year 2000 (tm)... "I will convert to Judasism and change my trademark Fa Shizzle My Nizzle to Sheiztle Fa Zeitzel." -- Snoop Dog
Hi.
I've written a patch for rsync that will recognize Mac OS X
HFS+ resource forks and metadata, and transfer them to a
remote non-HFS+ filesystem.
The resource forks and metadata are stored in an AppleDouble
file, using the ._<filename> naming scheme.
A few people have been helping me test the new version, and
I think it's working for everyone now. If anyone else cares
to give it a spin, I would appreciate it:
A diff, binary, and fuller explanation are available at:
http://www.quesera.com/reynhout/misc/rsync+hfsmode
This version of the patch is 1.2b, against rsync-2.6.3pre1.
Two known issues:
- rsync has an aversion to the special files in directory
/dev/fd, when-and-(we think)-only-when the SRCDIR is /.
simple solution: --exclude=/dev/fd/*
"proper" solution TBD, but the problem appears to be
unrelated to this hfs-mode patch.
- rsync-2.6.3pre1 doesn't work with BackupPC because of
some server side option processing. This is fixed in
CVS, so if you use BackupPC you should apply the patch
to a post-26Aug nightly, or to the current CVS tree.
I also have a patched binary of the 08Sep nightly.
Email for details.
Most of the testing has been from OS X 10.3.5 boxes to Solaris
or Linux destinations. Anyone with a more mixed environment
is especially encouraged to give it a run.
Thanks,
Andrew
reynhout@quesera.com