rsync - Oct 2013 - [Bug 10226] New: fatal_unsafe_io_error and the version it reports

https://bugzilla.samba.org/show_bug.cgi?id=10226

           Summary: fatal_unsafe_io_error and the version it reports
           Product: rsync
           Version: 3.1.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
        AssignedTo: wayned at samba.org
        ReportedBy: Martin.vGagern at gmx.net
         QAContact: rsync-qa at samba.org


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?

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=10226

Wayne Davison <wayned at samba.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Wayne Davison <wayned at samba.org> 2013-10-27
16:55:10 UTC ---
I'm checking in a fix for this now.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=10226

--- Comment #2 from Wayne Davison <wayned at samba.org> 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.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.