RFC: rsync extended attributes support

[cssdev@…]

There are existing ports for both rsync and hfsrsync, but neither of these include Apple's support for extended attributes. I created a rsync port that includes Apple's patches. The attached port is intended to duplicate building Apple's rsync 2.6.3 with extended attribute support (same as included in Mac OS X 10.4.3) using darwinports. However, this Portfile also includes patches that work around several Tiger rsync bugs as noted at the URL: ​http://www.lartmaker.nl/rsync/

This port also includes Apple's copyfile.h header and the Apple Public Source License. The idea here is to integrate Apple's rsync enhancements and the additional fixes from JDB in a port that can be easily built on other systems.

It has been recommend that I attempt to apply these patches to the latest rsync 2.6.6 port, so I'll see if I can get that working. There are some changes to the relevant portions of the code, so if I get that working, I'll upload those changes within this report.

[cssdev@…]

Apple rsync + EA patches port

[cssdev@…]

Apple's EA patches converted for 2.6.6

[cssdev@…]

rsync 2.6.6 eafixes Portfile and patches

[cssdev@…]

Fixed archive

[jmpp@…]

So Chris, what's the story on this? Have you made any further progress? Or do you believe your last entries on this bug are ready to be committed? Mark, as port maintainer, what's your take? Personally I believe the eafixes section should be included as a "darwin 8" platform declaration instead of a variant, given both that the fixes included therein are necessary on that platform and, secondly, they are not likely to work on any other platform (even darwin 7). Chriss, is this the case for every single patch you included? At this point I don't exactly recall, mind clarifying?

In any case, I'd really like to see this work integrated into the rsync port, most users will appreciate it I'm sure!

-jmpp

PS: Bugzilla seems to have acted up in some strange way, perhaps the db problems OpenDarwin is currently having. When I first tried to make these same comments to this bug, Bugzilla asked me to authenticate; upon successful login the result I got was that my comments were, instead, appended to a bug that was so old that it was fkr who closed it back then, so figure that! Trying again now to see if I get the right bug ;-)

[cssdev@…]

According to the EA fixes author, the patch does support other operating systems. For example, one could run rsync from a Mac OS X Tiger system to a FreeBSD server running the same patched version of rsync. On other operating systems, this patch should allow rsync to store the associated extended attributes data as sent from Mac OS X Tiger. I haven't had a chance to verify this (I haven't installed DarwinPorts onto my FreeBSD box at work yet). I did verify that this patch retained extended attributes and corrected modification dates for local transfers on my laptop. I would still prefer to see some other people verify everything works with their own files too, just to be safe.

[mww@…]

what about a rsync-devel port with all your most-cool patches? This way we can assure a stable rsync and get people to testing it w/o much pain.

Awaiting Portfile!

[cssdev@…]

rsync-ea port

[cssdev@…]

Portfile with enable-ea

[cssdev@…]

I just noticed another page with details about "fixing rsync on Tiger," but it identifies several other issues that are probably not addressed by the patches I'm using. ​http://www.onthenet.com.au/~q/rsync/

I also noticed that rsync 2.6.7 was just released. ​http://rsync.samba.org/ftp/rsync/rsync-2.6.7-NEWS

[cssdev@…]

For the sake of completeness, I'll also note the release of rsync 2.6.8: ​http://rsync.samba.org/ftp/rsync/rsync-2.6.8-NEWS

[cssdev@…]

I've been using this port to backup my hard drive for several months now, and it has properly preserved both resource forks and modification dates. Should we consider action on this port? Perhaps try to apply the changes to the latest version of rsync? Consider adding this test with a strong warning that it needs more testing?

[cssdev]

Should I commit this port for more open testing?

[cssdev]

I'll commit this as net/rsync-lart unless there are any major objections.

[cssdev]

Renames the port to rsync-lart and adjusts the distfile directories

[cssdev]

I committed rsync-lart in r22516. We'll see if it gets some use, but issues should go into new tickets. I'm marking this ticket closed for now.