Re: 2.6.0 file has vanished fails to set exit code on local client
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 vanished-file message if it is talking with a pre-28 protocol (I'm going to put an exit-code message into protocol 28). ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: 2.6.0 file has vanished fails to set exit code on local client
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 cause a daemon sender to go ahead and use FERROR for the vanished-file message if it is talking with a pre-28 protocol (I'm going to put an exit-code message into protocol 28). Sounds good. BTW, fixing the exit code bug in my rsync trigger script solved my exit code reporting problem. Rsync client now ends with: wrote 415849 bytes read 22037678 bytes 18797.43 bytes/sec total size is 6033963241 speedup is 268.73 rsync warning: some files vanished before they could be transfered (code 24) at main.c(1064) My script then reports: rsync exited with exit code 24 after 1195 seconds Exit Code 24 means a source file vanished. That's OK. Thanks again for the tip about the exit code not being returned from the remote shell. :) -- John Van Essen Univ of MN Alumnus [EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: 2.6.0 file has vanished fails to set exit code on local client
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.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: 2.6.0 file has vanished fails to set exit code on local client
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 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) I didn't get that message at all. 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? I am doing pulls (remote is the sender). The problem also occurs when pulling from a daemon. Are you by any chance doing internal rsyncs? The problem may not happen then (and it does not happen when doing pushes). But it definitely happens during pulls. I looked at the code (as explained in my original post) and I can see why this problem occurs on a pull. It won't occur on a push because it's the client (operating as a local sender) that sets IOERR_VANISHED, and thus it gets properly reported and the proper exit code is returned when pushing. BTW, how do you do a test case for a vanished file? You'd have to put a sleep ay the beginning of the generator or something to give you a chance to delete a file to make it vanish. For the record, here's the output when doing a non-daemon pull: ---8--- receiving file list ... done deleting prod/www/phpAdsNew-rc42/cache/cache-325b0aa69079bd5fb2bbead537628e67.php [ snip ] prod/www/phpAdsNew-rc42/cache/cache-4310ac3ccab0e7873e1b5e4056bbe0e8.php file has vanished: /gate/prod/www/phpAdsNew-rc42/cache/cache-45c4e1728897eaf542d0cbea598d6835.php prod/www/phpAdsNew-rc42/cache/cache-46a3b156b57fdd85debcc15af6a3669a.php prod/www/phpAdsNew-rc42/cache/cache-793adc31f64b57bc2cc180b7bf91368f.php file has vanished: /gate/prod/www/phpAdsNew-rc42/cache/cache-7e0cefc9e2ddcb62e4f4fd8e22f84926.php prod/www/phpAdsNew-rc42/cache/cache-813b0065c37ad3df50cf0f054667d076.php [ snip ] spool/mysql/test.dump.20040106.gz wrote 109283 bytes read 17331144 bytes 505519.62 bytes/sec total size is 3118698885 speedup is 178.82 rsync exited with exit code 0 after 35 seconds ---8--- (That last 'rsync exited' line is from my backup script, which always reports the exit code and the elapsed time for the rsync.) So as you can see, files vanished, no rsync error: message was displayed, and the exit code was 0. -- John Van Essen Univ of MN Alumnus [EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: 2.6.0 file has vanished fails to set exit code on local client
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 not getting the error. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
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 [EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
