Making rsync compile under Mac OS X 10.3.9 with extended attributes

[Vitorio]

Some answers for your questions:

1)
> rsync: ACLs are not supported on this client
> rsync error: syntax or usage error (code 1) at main.c(1454)  
> [client=3.0.0pre9]

  no, you can't use -A (--acls) option with this version of rsync, as  
you compiled it without. And it's impossible to compile it with ACL  
support in 10.3. As 10.3 and 10.4 doesn't use ACL, this shouldn't be  
a major issue. You should only be aware to do not transfer files from  
a 10.5 computer by a 10.3 one (like 2 systems on the same machine, or  
shared folders over the network), as it would loose ACLs.

2)
> you have this in configure:
>
> checking whether to support ACLs... running tests:
> checking for acl_get_file in -lacl... no
> checking for ACL support... no
> checking ACL test results... No ACL support found
>
> I just have:
>
> checking whether to support ACLs... no
>
> but maybe because on this one I disabled ACL's in configure...


Exactly. If you force --disable-acl-support it won't do some tests as  
you explicitly said to it to disable ACL. But the result is exactly  
the same.

3)
> then I ran the same test with your patched rsync in leopard using  
> the same options (no A):
>
> Verifying:    basic-permissions ... ok
> Verifying:           timestamps ...
>    Sub-test:    modification time ... ok
> ok
> Verifying:             symlinks ... FAIL
> Verifying:    symlink-ownership ... FAIL
> Verifying:            hardlinks ... ok
> Verifying:       resource-forks ... ok
> Verifying:         finder-flags ... FAIL
> Verifying:         finder-locks ... ok
> Verifying:        creation-date ... ok
> Verifying:            bsd-flags ... ok
> Verifying:       extended-attrs ...
>    Sub-test:             on files ... FAIL
>    Sub-test:       on directories ... FAIL
>    Sub-test:          on symlinks ... FAIL
> FAIL
> Verifying: access-control-lists ...
>    Sub-test:             on files ... FAIL
>    Sub-test:              on dirs ... FAIL
> FAIL
> Verifying:                 fifo ... ok
> Verifying:              devices ... ok
> Verifying:          combo-tests ...
>    Sub-test:  xattrs + rsrc forks ... FAIL
>    Sub-test:     lots of metadata ... FAIL
> FAIL
>
> it looks like rsync is not using the original patches for flags etc  
> but using yours instead perhaps? Is it supposed to override your  
> patch if the system is greater than 10.3.9? Or maybe because it was  
> compiled on 10.3.2?
>
> at any rate, huge progress. Thanks so much. I await any further  
> developments.  Rob
>
>
> ps the bouncer results without your patch and compiled on leopard:
>
> Verifying:    basic-permissions ... ok
> Verifying:           timestamps ...
>    Sub-test:    modification time ... ok
> ok
> Verifying:             symlinks ... ok
> Verifying:    symlink-ownership ... ok
> Verifying:            hardlinks ... ok
> Verifying:       resource-forks ... ok
> Verifying:         finder-flags ... ok
> Verifying:         finder-locks ... ok
> Verifying:        creation-date ... ok
> Verifying:            bsd-flags ... ok
> Verifying:       extended-attrs ...
>    Sub-test:             on files ... ok
>    Sub-test:       on directories ... ok
>    Sub-test:          on symlinks ... ok
> ok
> Verifying: access-control-lists ...
>    Sub-test:             on files ... ok
>    Sub-test:              on dirs ... ok
> ok
> Verifying:                 fifo ... FAIL
> Verifying:              devices ... FAIL
> Verifying:          combo-tests ...
>    Sub-test:  xattrs + rsrc forks ... ok
>    Sub-test:     lots of metadata ... ok
> ok

This behaviour is completely normal. The rsync functions are decided  
at the compilation time (maybe we should change some options to the  
execution time later, if it's possible?).
So the patched rsync compiled on 10.3 won't use ACLs and probably  
other functions, even if you use the program on 10.4 or 10.5. All  
functionalities are decided at the compilation time by the configure  
script.
In another hand, the patched rsync with 10.3 extended attributes  
support should compile as the unpatched one in 10.4 or 10.5 and  
present the same functionalities. This may be useless for people that  
don't use 10.3, but can be useful to have only one source code for  
all the systems and just recompile if needed.

4)
>  I did notice that applescript files didn't show up in the finder  
> but they were there if I ran ls command on the copy folder.
Could you give me more details about those files?
Do they have only resource fork or also data fork?
A simple way to verify:
ls -la /the/path/to/the/folder/having/the/problematic/file
than
ls -la /the/path/to/the/folder/having/the/problematic/file/rsrc

Example on a text clipping (that is pure resource fork):

iLaG:~/Desktop/rsync-3.0.0pre9 lag$ ls -la /Users/lag/Desktop/I\  
dragged\ a\ text\ clipping\ in.textClipping
-rw-r--r--   1 lag  lag  0 Jan 21 20:48 /Users/lag/Desktop/I dragged  
a text clipping in.textClipping
iLaG:~/Desktop/rsync-3.0.0pre9 lag$ ls -la /Users/lag/Desktop/I\  
dragged\ a\ text\ clipping\ in.textClipping/rsrc
-rw-r--r--   1 lag  lag  3951 Jan 21 20:48 /Users/lag/Desktop/I  
dragged a text clipping in.textClipping/rsrc

You can see that the normal file (the data fork) have a 0 size and  
the resource fork (/rsrc) have 3951 bytes. If I copy this file with  
the current (v0.2) version of the patched rsync it will disappear  
from the Finder. As it will be ok from the Terminal, if I try to copy  
it with the 10.4 cp (that is resource fork aware) it will not copy  
the resource fork and corrupt the destination file. So there is a  
problem there. I think that we are maybe missing a command after  
FSWriteFork to link the writed fork to the file. But I'm still  
investigating.

If you have mixed data fork/resource fork files (as Classic programs)  
it would be interesting to see if they are well copied by the patched  
rsync, and if you can copy the destination file with /Developer/Tools/ 
CpMac in 10.3 or simply cp in 10.4 and see if the resource fork is  
always there or if we have corrupted it. I didn't test yet this  
behavior, will do it as soon as possible, but more people testing  
goes faster to discover and fix bugs. So if you have some time to  
spend on it, go ahead ;)

Vitorio