DO NOT REPLY [Bug 5795] New: error in rsync protocol data stream(code 12) at io.c(632) [sender=3.0.4] - Tools

This is a discussion on DO NOT REPLY [Bug 5795] New: error in rsync protocol data stream(code 12) at io.c(632) [sender=3.0.4] - Tools ; https://bugzilla.samba.org/show_bug.cgi?id=5795 Summary: error in rsync protocol data stream (code 12) at io.c(632) [sender=3.0.4] Product: rsync Version: 3.0.4 Platform: x86 OS/Version: Mac OS X Status: NEW Severity: blocker Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: Dave@Yost.com QAContact: rsync-qa@samba.org 0 424 Z% ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: DO NOT REPLY [Bug 5795] New: error in rsync protocol data stream(code 12) at io.c(632) [sender=3.0.4]

  1. DO NOT REPLY [Bug 5795] New: error in rsync protocol data stream(code 12) at io.c(632) [sender=3.0.4]

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

    Summary: error in rsync protocol data stream (code 12) at
    io.c(632) [sender=3.0.4]
    Product: rsync
    Version: 3.0.4
    Platform: x86
    OS/Version: Mac OS X
    Status: NEW
    Severity: blocker
    Priority: P3
    Component: core
    AssignedTo: wayned@samba.org
    ReportedBy: Dave@Yost.com
    QAContact: rsync-qa@samba.org


    0 424 Z% rsync -av --sparse --progress --partial
    /Users/yost/Documents/VMWare/winxp.vmwarevm /Volumes/x/vmware
    sending incremental file list
    winxp.vmwarevm/
    winxp.vmwarevm/winxp.vmdk
    1578172416 17% 11.08MB/s 0:10:35
    rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32)
    rsync: connection unexpectedly closed (32 bytes received so far) [sender]
    rsync error: error in rsync protocol data stream (code 12) at io.c(632)
    [sender=3.0.4]
    12 425 Z% rsync --version
    rsync version 3.0.4 protocol version 30
    Copyright (C) 1996-2008 by Andrew Tridgell, Wayne Davison, and others.
    Web site: http://rsync.samba.org/
    Capabilities:
    64-bit files, 32-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes

    rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
    are welcome to redistribute it under certain conditions. See the GNU
    General Public Licence for details.
    0 426 Z%


    --
    Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
    ------- You are receiving this mail because: -------
    You are the QA contact for the bug, or are watching the QA contact.
    --
    Please use reply-all for most replies to avoid omitting the mailing list.
    To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


  2. DO NOT REPLY [Bug 5795] error in rsync protocol data stream (code12) at io.c(632) [sender=3.0.4]

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





    ------- Comment #1 from Dave@Yost.com 2008-09-27 18:23 CST -------
    It turns out there was clearly not enough space on the destination. The copy
    was going to take 20GB, and after the crash there was still 1GB on the
    destination, so I thought this was probably a protocol bug rather than a
    problem with running out of space.

    Perhaps what this is is a situation where the remote end should have sent back
    an indication that it was out of space and should have shut down gracefully.

    But there is another problem here: the two ends should start out by negotating
    whether there is enough space for the copy. In a better world, the destination
    OS would give the rsync process the ability to atomically grab disk resources
    up front to be used for the files and folders it creates, and if that fails,
    the remote rsync would tell the UI rsync no dice. Or how about this: writing
    the destination files could be transaction in the OS file system! Nah.


    --
    Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
    ------- You are receiving this mail because: -------
    You are the QA contact for the bug, or are watching the QA contact.
    --
    Please use reply-all for most replies to avoid omitting the mailing list.
    To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


  3. DO NOT REPLY [Bug 5795] look into a improved tear-down processingduring fatal errors

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


    wayned@samba.org changed:

    What |Removed |Added
    ----------------------------------------------------------------------------
    Severity|blocker |enhancement
    Status|NEW |ASSIGNED
    Summary|error in rsync protocol data|look into a improved tear-
    |stream (code 12) at |down processing during fatal
    |io.c(632) [sender=3.0.4] |errors




    ------- Comment #2 from wayned@samba.org 2008-10-02 13:53 CST -------
    Yes, the error reporting coming back from some errors can indeed be lacking.
    However, the pipe-lined nature of the protocol can make this hard to overcome
    (the error can be behind so much checksum data that it can't make it back prior
    to the connection getting torn down). In 3.1.0, I have a new option,
    --msgs2stderr, that can often be used to debug such situations (for non-daemon
    transfers).

    It would be good to investigate a reliable way to drain (and discard) the
    pending data to get all the relevant messages more reliably. For instance, if a
    new message was added "fatal exit in progress", it could be sent and circle the
    3 processes before the connection is torn down. e.g. a write error on the
    receiver sends the error message (text) to the generator, sends the fatal
    message too, and then just discards file-change data until it gets the fatal
    message back from the sender.


    --
    Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
    ------- You are receiving this mail because: -------
    You are the QA contact for the bug, or are watching the QA contact.
    --
    Please use reply-all for most replies to avoid omitting the mailing list.
    To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


  4. DO NOT REPLY [Bug 5795] look into a improved tear-down processingduring fatal errors

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





    ------- Comment #3 from Dave@Yost.com 2008-10-02 15:47 CST -------
    Why not have the process generating the error delay exit until it gets an ack
    of the error message? A separate connection would be best so the pipelined data
    doesn't get in the way.


    --
    Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
    ------- You are receiving this mail because: -------
    You are the QA contact for the bug, or are watching the QA contact.
    --
    Please use reply-all for most replies to avoid omitting the mailing list.
    To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


  5. DO NOT REPLY [Bug 5795] look into a improved tear-down processingduring fatal errors

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





    ------- Comment #4 from wayned@samba.org 2008-10-03 00:35 CST -------
    That's what I just said.


    --
    Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
    ------- You are receiving this mail because: -------
    You are the QA contact for the bug, or are watching the QA contact.
    --
    Please use reply-all for most replies to avoid omitting the mailing list.
    To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
    Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


+ Reply to Thread