Toni Pisjak [[EMAIL PROTECTED]] writes:
> My question: Is the exit status reliable in the current version ?
It's not 100% reliable, but it does somewhat depend on what you would
consider a failure, since there are some slightly ambiguous cases.
For my part, the cases where I've seen fit to make some local changes
to cover scenarios included the following:
* recv_files in receiver.c: There are 4-5 points where it can have a local
failure (fstat, getting a tmp name, etc...) that the stock code prints
a warning, but continues to the next file in the list. Depending on the
failure it may still exit out with a non-zero code, but in some cases
it'll just skip the problem file and continue on. I changed this to
abort with a non-zero code. (This does change control flow slightly in
that function but I haven't seen a problem yet, and receive_data that
is called from this function can also directly exit on an I/O failure).
* finish_transfer in rsync.c: Failures renaming the temporary file could
be ignored (I find this happens sometimes under NT) and you could lose
both the temporary ".filename" version and think it was successful. I
switched this to trigging an I/O error exit.
In my transfers, I got caught once in the first case when I ran out of
disk space, so the mktemp call was failing on all the files but
looking like the overall transfer was ok. The second case hit me
under NT (as noted above) sporadically - but certainly not frequently.
I haven't had the opportunity yet to suggest these changes back for
inclusion in the main source.
The only other issue that I've seen is the potential for the server
side to run into local problems, that get reflected as error messages
to the receiver, but don't stop the transfer or result in a non-zero
exit code. One case is a missing file on the server - you'll get a
link_stat warning message in the stream but if it was just one of
several files, the rest of the transfer will complete and it can look
successful. I was going to fix this until I realized that it actually
helped us in some transfers where a file might or might not be
present. I do think it should probably error out in the long run, but
haven't made any changes along those lines.
With all this said however, it took me about 6 months of using rsync
heavily to get to the point of making the changes I did, so these
aren't frequent occurrences, nor did they really impede my use of
rsync with scripts that strictly watched the exit code. Also, in all
of these cases, there is a warning or error message that gets
displayed, but you'd have to parse the rsync output to see it rather
than just trusting the exit code.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: [EMAIL PROTECTED] /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
