I just got the following output from an rsync run: rsync: readlink_stat("/home/mvg/mnt/tmp1") failed: Permission denied (13) FATAL I/O ERROR: dying to avoid a --delete-delay issue with a pre-3.0.7 receiver. rsync error: requested action not supported (code 4) at flist.c(1882) [sender=3.1.0] The named path is the mount point of an sshfs, so I'm not extremely surprised that something might be going wrong there. What DOES surprise me is the claim about the receiver being pre-3.0.7, since the receiver is actually a 3.0.9 from Debian wheezy. 3.0.9-4 to be precise. The sending side is 3.1.0 on Gentoo. rsync version 3.0.9 protocol version 30 Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes rsync version 3.1.0 protocol version 31 Copyright (C) 1996-2013 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes, prealloc Did someone simply plug in the wrong version number in that error message? Or is it that the problem should have been avoidable with 3.0.9, and the fact that it didn't indicates some more severe problem somewhere?
I'm checking in a fix for this now.
I should mention that the issue is that the client is not letting the server side know (via -Ef flag) that it has the fixed delete logic available (for older protocols). I should have made the fixed versions of rsync notice if the remote's offered protocol version was > 30 and have it assume that the 'f' flag was in effect (allowing the flag to be retired), but since that didn't happen, we need to continue to offer it, just in case the remote side needs the indicator.