Bug 10272 - resource fork handling is broken in 3.1.0
resource fork handling is broken in 3.1.0
Status: RESOLVED FIXED
Product: rsync
Classification: Unclassified
Component: core
3.1.0
All Mac OS X
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-16 23:28 UTC by David K
Modified: 2013-11-25 21:13 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David K 2013-11-16 23:28:33 UTC
In rsync 3.1.0, when rsyncing between two Macs running OS X (I've tried with both Mountain Lion and Snow Leopard), rsync -vaX chokes on files with resource forks, with the following error message:

$ rsync -vaX test2-20131116 remotehost:/tmp/
sending incremental file list
need to write 836037 bytes, iobuf.out.buf is only 65532 bytes.
rsync error: protocol incompatibility (code 2) at io.c(599) [sender=3.1.0]

Note that the directory "test2-20131116" contained a single file with a 836037-byte resource fork.  (Perhaps the problem arises only with resource forks larger than some default buffer size?)

Both sides of this attempted transfer were running rsync 3.1.0.  When, instead, both sides were running rsync 3.0.9, there was no error message and the resource fork transferred (apparently) correctly.
Comment 1 Mike Bombich 2013-11-17 18:11:50 UTC
resource fork data needs to be chunked in sys_lgetxattr(). The changes to accommodate this are already in the hfs-compression patch, though it's probably a good idea to get the lib/sysxattr.c changes that are more generally applicable to OS X moved into the main branch.
Comment 2 Wayne Davison 2013-11-25 21:13:40 UTC
This error looks like the read happened fine, but it tried to write the huge resource fork in one buffer call that didn't support flushing the buffer between chunks.  I'm checking in a change that will fix this.  I'm also moving the chunked xattr reading from the hfs-compression patch into the main OS X code.  Committed to git.