2.6.2 not displaying permissions errors on client side
cbarratt at users.sourceforge.net
Mon May 31 15:35:02 GMT 2004
Wayne Davison writes:
> On Sun, May 09, 2004 at 03:35:47AM -0700, Robert Helmer wrote:
> > If there is an error writing to the remote file due to a "permission
> > denied" error, rsync 2.6.1's client exits with an error code of 23, and
> > an informative error message.
> ... and no error message logged in the server's log file.
> Rsync has historically been hesitent to return error messages from a
> server to the client for fear of revealing too much information. The
> 2.6.0 and 2.6.1 releases were returning error messages but failing to
> log them in the server's log file. The 2.6.2 release reverts back to
> the historical way this was handled.
> A better solution for the future would be to log all errors to the
> server log and send some/most of them to the user as well. However,
> that will be a complex change, and it has not been worked on yet.
> A simpler solution would be to duplicate ALL the messages (the lack of
> selectivity make this change easy). The appended patch should do this,
> if you so desire to go that route.
Thanks for the patch. I strongly vote for rsync errors being delivered
to the client and would like to see this default again in the next
version (perhaps with a command-line switch if necessary?). In my case
with BackupPC it emulates an rsync client and it needs to see client
errors so it can log and count them, and for client read errors it needs
to remove the bad file which is otherwise zero-filled (this happens with
locked files on cygwin/WinXX).
I saw your patch that returns a bad file checksum in the case of read
errors. The drawback is the bad file requires two passes, since it
will fail on both passes, but retrying the file is probably worthwhile
in case the failure was intermittent.
More information about the rsync