rsync - Jan 2004 - 2.6.0 "file has vanished" fails to set exit code on local client

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 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 transfer phase).

The old scheme used FERROR for the ""send_files failed to open"
message.
The new scheme uses FINFO for the "file has vanished:" message.

The client receiver sets log_got_error when it receives a FERROR
message from the sender.

The old scheme used (io_error || log_got_error) to report a
partial transfer (with no alternative of vanished files).

The new scheme uses the IOERR_VANISHED flag to distinguish the
two errors, and it will never be set in an rsync pull (nor will
log_got_error get set if vanished files are the only errors).
Hence, the exit code stays 0.

Furthermore, if the local client is pre-2.6.0 and the remote server
is 2.6.0, the same problem happens, since the only thing pre-2.6.0
keys on is an FERROR message coming from the server during the
file transfers.  So now it also (incorrectly) exits with a 0 exit
code in the case of partial transfers from a 2.6.0 server.

So this needs some work...

- On the server, if the client protocol is < 27, use FERROR instead
  of FINFO so the pre-2.6.0 client can use a RERR_PARTIAL exit code.

- On the client side, it has to somehow recognize the vanished error
  on the server.  It could examine each FINFO message that comes
  over to see if it begins with "file has vanished:" and set the
  IOERR_VANISHED flag (but that's pretty kludgy...).

I haven't coded anything pending review of this bug by whoever
coded the IOERR_VANISHED feature to verify my analysis.  (Wayne?)
-- 
        John Van Essen  Univ of MN Alumnus  <vanes002@umn.edu>

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 transfer phase).
Yes it is, it is passed as the exit code.  In the tests I just ran, the
new error message appears if both sides are 2.6.0:

rsync warning: some files vanished before they could be transfered (code 24) at
main.c(1064)

and the new error code (24) is still returned when a 2.6.0 rsync is
sending to an older rsync (though the error is unexplained):

rsync error: unexplained error (code 24) at main.c(1045)

The old message appears if the sending side is 2.5.7 or older (here the
receiver is 2.6.0):

rsync error: some files could not be transferred (code 23) at main.c(1064)

So, what test case do you have that shows a failure?

..wayne..