Xattrs and Delete over AFP

[zodiac-meow at usa.net]

Thank you for your prompt response Matt.

> On Sat, 2008-06-21 at 21:34 -0400, zodiac-meow at 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