Buggy E-flag in Tiger's rsync

[DominikHoffmann]

I just discovered the -E flag in Tiger's rsync, which is supposed to signal to rsync to preserve the "extended attributes," that is, the file attributes and the resource forks of files during synchronization operations. Prior to Tiger, there were alternatives to the standard rsync that had to be used, if one wanted to preseve the extended attributes.

Using a user home folder, which is used by the user in question almost exclusively from his Windows workstation, attempting to copy it to a FireWire drive formatted for Windows, I tried the -E flag:

rsync -avE --delete-after /Volumes/RAID/UserHomes/#####/ /Volumes/EXTERNAL_HD/TGEN\ Backup\ files/#####/

The resulting operation proceeded but then interrupted before finishing:

building file list ... done
./
.CFUserTextEncoding
.Trash/
file has vanished: "/Volumes/RAID/UserHomes/#####/._.DS_Store"
file has vanished: "/Volumes/RAID/UserHomes/#####/._.Trash"
Compounds/
Compounds/Amidines/

...

Documents/Collaborations/Rothstein JHU/._#####.doc
Documents/Collaborations/#####/#####.doc
rsync: writefd_unbuffered failed to write 32768 bytes: phase "unknown" [sender]: Broken pipe (32)
Documents/Collaborations/#####/

...

Documents/Orders/#####/
rsync: connection unexpectedly closed (352487 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-20/rsync/io.c(359)
rsync: connection unexpectedly closed (5328 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-20/rsync/io.c(359)
mainserver:~

When I omit the -E flag, everything works fine and completes properly. Is this a bug?

Yours,

Dominik Hoffmann

[DominikHoffmann]

Apple acknowledges this as a bug, which they are already tracking.

Dominik Hoffmann