Bug 10226 - fatal_unsafe_io_error and the version it reports
fatal_unsafe_io_error and the version it reports
Status: RESOLVED FIXED
Product: rsync
Classification: Unclassified
Component: core
3.1.0
All All
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-24 06:53 UTC by Martin von Gagern
Modified: 2013-10-27 16:58 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 Martin von Gagern 2013-10-24 06:53:09 UTC
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?
Comment 1 Wayne Davison 2013-10-27 16:55:10 UTC
I'm checking in a fix for this now.
Comment 2 Wayne Davison 2013-10-27 16:58:43 UTC
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.