Archive of "bad" things during rsync?

[Tuc at T-B-O-H.NET]

> On Fri, 2008-05-30 at 12:16 -0400, Tuc at T-B-O-H.NET wrote:
> > 	Wouldn't you know, I can't get rsync to throw an error during
> > a copy. :) I need to put together some instructions for a guy that runs
> > a WISP for him to look over before weekly backups are made (I'll be
> > copying the files to /dev/null so any read errors can be caught).
> 
> > 	[...] does anyone have an archive of whats possible? Or even better a=20
> > regexp set of rules for scanning the output? Or do I just troll google an=
> d=20
> > the archives for "rsync error:"?
> 
> Rsync has both individual error messages and exit codes, which
> correspond to generic error messages.  You can find the list of exit
> codes and corresponding messages in the source:
> 
> http://gitweb.samba.org/?p=3Drsync.git;a=3Dblob;f=3Derrcode.h
> http://gitweb.samba.org/?p=3Drsync.git;a=3Dblob;f=3Dlog.c#l67
> 
> (There's a list in the man page but it's out of date.)
> 
> To find the individual error messages, search the source for FERROR:
> 
> =EF=BB=BFhttp://gitweb.samba.org/?p=3Drsync.git&a=3Dsearch&h=3DHEAD&st=3Dgr=
> ep&s=3DFERROR
> 
> There's a ton of these, but they fall into a few categories.  Fatal
> errors (e.g., disruptions in the protocol) are followed by a call to
> exit_cleanup with the appropriate exit code.  Nonfatal errors that may
> affect the correctness of the transfer use FERROR_XFER, which makes
> rsync exit with code 23 when it finishes the run; severe nonfatal errors
> may set IOERR_GENERAL, which additionally inhibits deletion unless
> --ignore-errors is on.
> 
> Two common causes of code 23 errors come to mind: nonexistence of the
> source or destination and lack of permission either to read the source
> files or to set the desired attributes on the destination files.  These
> generally show up as "[system call name (filename)] failed: No such file
> or directory" or "Permission denied" or "Operation not permitted".
> 
> I don't know what to say to the WISP admin beyond this.  There's no
> substitite for some unixy common sense.  If the admin gets an error
> message that he can't figure out, he can always ask on the list.
> 
> Matt
> 
Hi Matt,

	Thanks. I will look at the references provided and try to see
if I can put together something for him.

	As for the error before, no need to debug it. I caused it by 
a CTRL-C during sending. It was the only error I know how to cause
directly except for the warning that files vanished. Sorry to not
include that.

	As for the offer to let the admin loose on the list, you 
REALLY don't want that.... This is the same guy that figured he'd
throw a 500G disk into a machine that already had an 80G, 
dd if=/dev/hda of=/dev/hdb, and then rebooted. In olden *nix you
probably could get away with it as long as you didn't mind wasting
420G of disk, but with the ability of Linux to mount LABELS instead
of partitions... It got confused seeing 2 LABEL=/tmp and wouldn't
boot. So yea, he's got a bit of unixy knowledge which makes him
dangerous (Like the other time he figured he'd pretend after all
the hardening I did on the machine to change /etc/motd to look like
a hacker got in and freaked the #%@$@#$#@$ out of me trying to do
forensics for 4 hours)

		Thanks, Tuc