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
-- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
