Thank you for your prompt response Matt.
> On Sat, 2008-06-21 at 21:34 -0400, zodiac-meow@usa.net wrote:
> > I have an OSX 10.3.9 Server that I'm trying to back up with rsync
3.0.2.
> > Since I didn't have any luck with the 10.3.9 patch
>
> To be perfectly clear, do you mean you have tried Vitorio Machado's
> patch?
>
> http://lists.samba.org/archive/rsync/2008-February/020093.html
>
> If not, that may be worth a try.
I think I had tried a different version. This patch applied to the current
3.0.2 build fine except for rsync.h, which it interpreted to be a reverse
patch. I skipped that one and tried to build on my 10.3.9 station. The
Autoconf wasn't a high enough version so I tried to build on 10.4 using
--build=powerpc-apple-darwin7.9.0. It built after telling me to run "make
reconfigure" but wouldn't execute on 10.3.9 due to a reference to
lchown. So
I upgraded Autoconf on 10.3.9 and it compiled with only a few warnings:
gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c
clientname.c -o clientname.o
clientname.c: In function `compare_addrinfo_sockaddr':
clientname.c:269: warning: long int format, int arg (arg 4)
gcc -std=gnu99 -I. -I. -framework Carbon -g -O2 -DHAVE_CONFIG_H -Wall -W
-I./popt -c lib/sysxattrs.c -o lib/sysxattrs.o
lib/sysxattrs.c: In function `sys_fgetxattr':
lib/sysxattrs.c:277: warning: unused parameter `filedes'
lib/sysxattrs.c:277: warning: unused parameter `name'
lib/sysxattrs.c:277: warning: unused parameter `value'
lib/sysxattrs.c:277: warning: unused parameter `size'
lib/sysxattrs.c: In function `sys_lremovexattr':
lib/sysxattrs.c:389: warning: unused parameter `path'
lib/sysxattrs.c:389: warning: unused parameter `name'
gcc: -framework: linker input file unused because linking not done
gcc: Carbon: linker input file unused because linking not done
I ran the backup bouncer on it and got these results:
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 ... 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
If I understand things correctly, Apple didn't introduce an API for extended
attributes until 10.4 so they shouldn't exist on a 10.3 server. ACLs
shouldn't
be expected either. And it works on most files OK. So far, so good. It does
gets this error on some files and directories:
rsync: get_xattr_names: llistxattr(" New Art Dept/John:Projects",1024)
failed:
Invalid argument (22)
I've narrowed this down to it being only file or directory names with a
"/" in
them (which OSX translates into a ":" in terminal). This doesn't
occur when
using an rsync without the pre-Tiger patch. This is still great news though!
So close...
> This may just be an oddity with the network filesystem, but that
doesn't
> explain why it would happen only with a --delete option, which
shouldn't
> significantly change rsync's access pattern to the network-mounted
> source. If you ktrace the relevant rsync process with and without
> --delete, that might provide some clues about what triggers the error.
>
> Since the error only happens with --delete and appears to involve
> xattrs, you may be able to work around it by using two passes of rsync,
> the first with -X but not --delete and the second with --delete but not
> -X.
I eventually got it to error without the --delete option as well. The ktrace
shows normal fetches followed by get errors like this:
1051 rsync CALL getdirentries(0x3,0x1807600,0x1000,0x37941d4)
1051 rsync RET getdirentries 64/0x40
1051 rsync CALL lstat(0xbfffd85c,0xbfffe05c)
1051 rsync NAMI "City-140-200244/140-200244-A-A to Z
Tra-693418A/44.Page.A-A to Z Trailer Sales"
1051 rsync RET lstat 0
1051 rsync CALL getattrlist(0xbfffe714,0xbfffd7b8,0x93848,0xc,0x1)
1051 rsync NAMI "City-140-200244/140-200244-A-A to Z
Tra-693418A/44.Page.A-A to Z Trailer Sales"
1051 rsync RET getattrlist 0
1051 rsync CALL listxattr(0xbfffe714,0x1801800,0x400,0x1)
1051 rsync NAMI "City-140-200244/140-200244-A-A to Z
Tra-693418A/44.Page.A-A to Z Trailer Sales"
1051 rsync RET listxattr 44/0x2c
1051 rsync CALL getxattr(0xbfffe714,0x1801800,0,0,0,0x1)
1051 rsync NAMI "City-140-200244/140-200244-A-A to Z
Tra-693418A/44.Page.A-A to Z Trailer Sales"
1051 rsync RET getxattr 3212/0xc8c
1051 rsync CALL getxattr(0xbfffe714,0x1801800,0x1804200,0xc8c,0,0x1)
1051 rsync NAMI "City-140-200244/140-200244-A-A to Z
Tra-693418A/44.Page.A-A to Z Trailer Sales"
1051 rsync RET getxattr -1 errno 9 Bad file descriptor
1051 rsync CALL write(0x2,0xbfffc3a0,0xb0)
1051 rsync GIO fd 2 wrote 176 bytes
"rsync: get_xattr_data:
lgetxattr("City-140-200244/140-200244-A-A to Z
Tra-693418\
A/44.Page.A-A to Z Trailer
Sales","com.apple.ResourceFork",3212)
failed: Bad fil\
The inconsistency of the files it errors on lead me to believe AFP is to
blame. It's never the same file twice. It also looks like it fails to
report
the existence of some files and directories because rsync will delete items
that are still in the source. I think I'll file this under "B"
for bad idea.
Thanks again for your help with this.
Mike