On Tue, Jan 13, 2004 at 11:45:22PM -0600, John Van Essen wrote:
But as I mentioned, it also happens with a daemon
Yeah, the daemon's exit code is not available to the client, so it is
getting lost. I've committed a patch that will cause a daemon sender to
go ahead and use FERROR for the
On Thu, 15 Jan 2004, Wayne Davison [EMAIL PROTECTED] wrote:
On Tue, Jan 13, 2004 at 11:45:22PM -0600, John Van Essen wrote:
But as I mentioned, it also happens with a daemon
Yeah, the daemon's exit code is not available to the client, so it is
getting lost. I've committed a patch that will
On Wed, Jan 07, 2004 at 02:11:35AM -0600, John Van Essen wrote:
But if the client is local and the server is remote, IOERR_VANISHED
gets set on the remote server, but is never passed to the local
client (the io_error value is passed at the end of the file list,
not during or after the file
On Tue, 13 Jan 2004, Wayne Davison [EMAIL PROTECTED] wrote:
On Wed, Jan 07, 2004 at 02:11:35AM -0600, John Van Essen wrote:
But if the client is local and the server is remote, IOERR_VANISHED
gets set on the remote server, but is never passed to the local
client (the io_error value is passed
On Tue, Jan 13, 2004 at 10:38:23PM -0600, John Van Essen wrote:
Are you by any chance doing internal rsyncs?
No. What remote shell are you using? If it doesn't propagate the exit
code from the sender (i.e. the process on the other side of the
connection), that may explain why the receiver is
A new 2.6.0 feature is supposed to use a different exit code when the
only 'errors' were from files that disappeared between the building
of the file list and the actual transfer of files.
But if the client is local and the server is remote, IOERR_VANISHED
gets set on the remote server, but is
