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

Wesley D Craig wes at umich.edu
Fri Mar 12 17:04:36 GMT 2004


On 12 Mar 2004, at 11:17, D Andrew Reynhout wrote:
> I think the maintainers have to err on the side of caution
> regarding changes to the application, and especially to the
> protocol.

My preference is to not adjust the protocol, at least not for HFS+ 
support.  I don't think it's necessary or particularly desirable.  In 
particular, I don't see much value in making rsync changes that destroy 
my ability to store data on arbitrary volumes.  I think it ought to be 
up to the oddball filesystems to deal with their oddball-ness.

> The problem, as I see it (usual disclaimers apply), is that
> rsync depends in many places on a very strict sourcefile-to-
> destinationfile mapping.  To make the sourcefile "virtual",
> i.e. created on the fly, would require deep restructuring
> (and extra memory).

Certainly there might be additional memory requirements for the HFS+ 
system.  For instance, if you decided that you wanted to send resource 
forks and finder info encoded as with AppleDouble, you'd need to 
construct the finder info (32 bytes) and the AppleDouble header (50 
bytes) before sending them along.  Of course, you probably don't need 
to allocate this memory for each file.  You could have just one, used 
to marshal the data just before sending.

> Filesystem designers
> should make the metadata more accessible* but all modern
> filesystems have metadata, and I think it will only get more
> important as time goes on.

Personally, I'm not out to change the world.  I'd just like a version 
of rsync that works between Macs & Everyone Else, while preserving a 
reasonable subset of the data.  As one of the authors of netatalk and 
radmind, both of which do this with some success, I'm pretty sure it's 
not too much to ask.

:wes



More information about the rsync mailing list