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
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.
More information about the rsync