2.6.0 "file has vanished" fails to set exit code on local client

[John Van Essen]

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 at umn.edu>