various xattr problems. Was: Re: internal abbrev error! ?

[Giuliano Gavazzi]

On 13 Jan 2008, at 08:06, Wayne Davison wrote:

> On Sat, Jan 12, 2008 at 08:29:43PM +0000, Max Lane wrote:
>> [receiver] internal abbrev error!
>
> Aha, I fixed on on the sending side, but yours is on the receiving  
> side.
> I just checked-in a change that should hopefully fix that too.  If you
> could give the latest dev version a try, I'd like to know if that  
> fixes
> it for you.  (See git, latest nightly tar file, etc.)
>
> ..wayne..

[Configuration: MacOSX 10.5.1 Intel. rsync from internal drive to  
external firewire 800.]

It appears that can this internal abbrev error (and others) still  
appear on the sending side with pre8 in a dry run (-n):

bash-3.2# date;  /usr/local/bin/rsync -avcinAX --stats --rsync-path=/ 
usr/local/bin/rsync \
--exclude='Library/Caches' --exclude='Library/Mail*' /BACKUPS/ 
albook.local/Users/a/ \
/Volumes/imega2/albookabackup/; date
Sun Feb  3 12:33:31 CET 2008
sending incremental file list
.d..t....a. ./
 >fc.t...... .DS_Store
[...]
.d..t...... .Trash/
 >f+++++++++ .Trash/Complete GIOS PDF 2007 Catalogue.zip
[sender] internal abbrev error!
rsync error: error in rsync protocol data stream (code 12) at  
xattrs.c(565) [sender=3.0.0pre8]
rsync: writefd_unbuffered failed to write 82 bytes [generator]: Broken  
pipe (32)
Sun Feb  3 12:33:46 CET 2008



it happens on a file with xattrs:

xattr ".Trash/Complete GIOS PDF 2007 Catalogue.zip"
com.apple.metadata:kMDItemWhereFroms
com.apple.quarantine

Running without -n transfers the file correctly.
I stopped midway this last transfer to see if the dry run would error  
again on that same file, but it did not. It did however error at a  
different point with another error:

dry run:
[...]
 >fc.t...... Documents/Downloads/.DS_Store
[sender] could not find xattr #13 for Documents/Downloads/ 
0182642479-0108.pdf
rsync error: error in rsync protocol data stream (code 12) at  
xattrs.c(561) [sender=3.0.0pre8]
Sun Feb  3 13:20:00 CET 2008

bash-3.2#   xattr -l Documents/Downloads/0182642479-0108.pdf
com.apple.FinderInfo:
0000   00 6E 00 63 00 65 00 73 00 00 00 00 00 00 00  
00    .n.c.e.s........
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00    ................

again a normal run transfers the file and a subsequent dry run does  
not give any error on that file.
However another problem appears, apparently triggered by the checksum  
option (-c): at apparently random and not necessarily big files, the  
process hangs.

Sorry to post on different issues at the same time...

Giuliano