rsync - Jan 2007 - DO NOT REPLY [Bug 4320] New: Daemon should send stdout, stderr of {pre, post}-xfer command to client

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

           Summary: Daemon should send stdout, stderr of {pre,post}-xfer
                    command to client
           Product: rsync
           Version: 3.0.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P3
         Component: core
        AssignedTo: wayned@samba.org
        ReportedBy: hashproduct+rsync@gmail.com
         QAContact: rsync-qa@samba.org


It would be nice if an rsync daemon returned data that the pre-xfer or
post-xfer command writes to stdout or stderr to the rsync client in the form of
MSG_INFO and MSG_ERROR messages.

This enhancement would be good for two reasons:

- Pre-xfer and post-xfer commands could report progress and errors to the user.
 In particular, a pre-xfer command could provide a meaningful error message to
accompany rsync's "pre-xfer exec returned failure".

- An rsync daemon would be much more useful as a general-purpose daemon for
remote command execution coupled with file transfer.  For example, I could
script an automated programming contest judge around an rsync daemon.  A
competitor would upload a submission to a module, and the post-xfer script
would grade the submission and send back the results via stdout.


-- 
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.

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





------- Comment #1 from hashproduct+rsync@gmail.com  2007-01-02 21:52 MST
-------
Sending the output of the post-xfer command would be harder than I originally
thought because the daemon currently does not run the post-xfer command until
after it has closed the connection to the client.  Furthermore, as soon as the
receiving side has received all the files, it drops the connection.  So when a
daemon sends files to an old client, the daemon has no way to make the client
wait around for extra messages.  Of course, new clients could wait for extra
messages followed by a special goodbye after pulling files from a daemon using
protocol 30.


-- 
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.

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





------- Comment #2 from hashproduct+rsync@gmail.com  2007-09-22 23:24 CST
-------
Created an attachment (id=2927)
 --> (https://bugzilla.samba.org/attachment.cgi?id=2927&action=view)
Patch to send pre-xfer output to client on error

Here is a quick-and-dirty patch that makes the daemon return output from the
pre-xfer command's stdout and stderr to the client *if* the pre-xfer command
fails.  Unfortunately, rsync seems to escape newlines in the output.


-- 
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.

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

Wayne Davison <wayned at samba.org> changed:

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

--- Comment #3 from Wayne Davison <wayned at samba.org> 2011-06-04
19:05:49 UTC ---
I prefer to leave stderr unaffected.  This provides a way for someone to debug
their scripts using rsync --daemon --no-detach (and avoids unintended messages
being sent to the user).

I have checked in a change that sends stdout to the user when the script
returns an exit status (so, only on failure).  To return a message on success
would require setting a global and outputting it later on in another file than
clientserver.c (after the protocol gets fully setup), and is not something that
I'm inclined to do at the moment.

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