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