<HTML>
<HEAD>
<TITLE>Protocol stream error copying extended attribute, silent failure to copy all data</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>I'm using rsync 3.0.7 on Mac OS X 10.6, compiled with HFS+ enhancements according to Mike Bombich's instructions at <a href="http://www.bombich.com/rsync.html">http://www.bombich.com/rsync.html</a>. Rsync repeatedly exits with a protocol data stream error on some com.apple.FinderInfo extended attributes. While testing this issue, I found that rsync is not copying all extended attributes even when there is no error message. I'm using a folder of fonts as an example, but I have experienced the protocol error when copying other data. This seems like a huge bug, and in my experience those often turn out to be operator error. Apologies if I waste anyone's time.<BR>
<BR>
In this example, I'm using rsync to make a copy from scratch of the source data: rsync307 -aX --delete Licensed\ Fonts /Volumes/Storage/<BR>
<BR>
I repeatedly get this error:<BR>
<BR>
[sender] internal abbrev error on Licensed Fonts/Postscript/bradley (com.apple.FinderInfo, len=32)!<BR>
rsync error: error in rsync protocol data stream (code 12) at xattrs.c(636) [sender=3.0.7]<BR>
<BR>
If you repeat the command a few times, sometimes the error is:<BR>
<BR>
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)<BR>
rsync: connection unexpectedly closed (16827 bytes received so far) [sender]<BR>
rsync error: error in rsync protocol data stream (code 12) at io.c(601) [sender=3.0.7]<BR>
<BR>
In all my testing, I have only seen the error occur with a com.apple.FinderInfo attribute, and only for a directory.<BR>
<BR>
Running rsync with sudo gives the same error.<BR>
<BR>
The system has no problem reading the extended attribute from the source folder, or using the xattr command to write it to the target folder:<BR>
<BR>
matt$ xattr -l Licensed\ Fonts/Postscript/bradley/<BR>
com.apple.FinderInfo:<BR>
00000000 03 99 01 5D 04 7C 02 2F 07 A0 5A 50 00 01 02 07 |...].|./..ZP....|<BR>
00000010 FF F8 FF F0 C3 40 00 00 00 00 00 00 00 01 6C 28 |.....@........l(|<BR>
00000020<BR>
matt$ xattr -l /Volumes/Storage/Licensed\ Fonts/Postscript/bradley/<BR>
matt$ xattr -wx com.apple.FinderInfo "`xattr -px com.apple.FinderInfo Licensed\ Fonts/Postscript/bradley/`" /Volumes/Storage/Licensed\ Fonts/Postscript/bradley/<BR>
matt$ xattr -l /Volumes/Storage/Licensed\ Fonts/Postscript/bradley/<BR>
com.apple.FinderInfo:<BR>
00000000 03 99 01 5D 04 7C 02 2F 07 A0 5A 50 00 01 02 07 |...].|./..ZP....|<BR>
00000010 FF F8 FF F0 C3 40 00 00 00 00 00 00 00 01 6C 28 |.....@........l(|<BR>
00000020<BR>
<BR>
After manually setting the extended attribute, the rsync command completes without error messages. The process is repeatable, always choking on the bradley folder.<BR>
<BR>
After rsync completed without error messages, I compared the sizes of source and copy:<BR>
<BR>
matt$ du -k -d1 /Installers/Licensed\ Fonts/<BR>
245196 /Installers/Licensed Fonts//Adobe Font Folio - OpenType Edition<BR>
51800 /Installers/Licensed Fonts//OpenType<BR>
256756 /Installers/Licensed Fonts//Postscript<BR>
43308 /Installers/Licensed Fonts//TrueType<BR>
598692 /Installers/Licensed Fonts/<BR>
matt$ du -k -d1 /Volumes/Storage/Licensed\ Fonts/<BR>
245196 /Volumes/Storage/Licensed Fonts//Adobe Font Folio - OpenType Edition<BR>
51800 /Volumes/Storage/Licensed Fonts//OpenType<BR>
246540 /Volumes/Storage/Licensed Fonts//Postscript<BR>
38528 /Volumes/Storage/Licensed Fonts//TrueType<BR>
583696 /Volumes/Storage/Licensed Fonts/<BR>
<BR>
My understanding is that the sizes should match. The number of items in each is the same:<BR>
<BR>
matt$ du -a /Installers/Licensed\ Fonts/ | wc -l<BR>
11916<BR>
matt$ du -a /Volumes/Storage/Licensed\ Fonts/ | wc -l<BR>
11916<BR>
<BR>
I saved the output of 'du -a' for source and copy, then ran a diff. There are hundreds of differences, and it appears that many extended attributes were not copied. Here's a typical example:<BR>
<BR>
matt$ ls -lh Licensed\ Fonts/TrueType/CCZoinks/CCZoinks.t1 <BR>
-rwx------@ 1 matt matt 0B Jul 16 1999 Licensed Fonts/TrueType/CCZoinks/CCZoinks.t1<BR>
matt$ ls -lh Licensed\ Fonts/TrueType/CCZoinks/CCZoinks.t1/..namedfork/rsrc<BR>
-rwx------ 1 matt matt 9.5K Jul 16 1999 Licensed Fonts/TrueType/CCZoinks/CCZoinks.t1/..namedfork/rsrc<BR>
<BR>
matt$ ls -lh /Volumes/Storage/Licensed\ Fonts/TrueType/CCZoinks/CCZoinks.t1 <BR>
-rwx------@ 1 matt matt 0B Jul 16 1999 /Volumes/Storage/Licensed Fonts/TrueType/CCZoinks/CCZoinks.t1<BR>
matt$ ls -lh /Volumes/Storage/Licensed\ Fonts/TrueType/CCZoinks/CCZoinks.t1/..namedfork/rsrc<BR>
-rwx------ 1 matt matt 1B Jul 16 1999 /Volumes/Storage/Licensed Fonts/TrueType/CCZoinks/CCZoinks.t1/..namedfork/rsrc<BR>
<BR>
The file is actually a PostScript Type 1 font, where all the content is in the resource fork. Rsync created a com.apple.ResourceFork attribute on the new file, but the attribute is empty.<BR>
<BR>
After this discovery, I ran my original rsync command again, then checked sizes:<BR>
<BR>
matt$ du -kd1 /Volumes/Storage/Licensed\ Fonts/<BR>
245196 /Volumes/Storage/Licensed Fonts//Adobe Font Folio - OpenType Edition<BR>
51800 /Volumes/Storage/Licensed Fonts//OpenType<BR>
254488 /Volumes/Storage/Licensed Fonts//Postscript<BR>
42216 /Volumes/Storage/Licensed Fonts//TrueType<BR>
595332 /Volumes/Storage/Licensed Fonts/<BR>
<BR>
More data was copied, but it's still missing some. Overall, it took 6 runs of the same rsync command to produce a copy that's the same size as the original.<BR>
<BR>
Is this a bug? Should I be using different flags in my rsync command?<BR>
<BR>
Matt<BR>
</SPAN></FONT>
</BODY>
</HTML>