--force exists to force --delete to work even when there are errors.  That is the only behaviour that rsync changes based on errors.  So what would you expect --ignore-errors to change when there is no --delete?

Yes. we must have --ignore-errors independent of --delete and also --force independent of --delete. sometimes we may not use --delete at all and want to continue with rsync even when errors are there and also sometimes rsync may refuse to run, so --force.

Rsync does continue on errors unless those errors are fatal (like a failure to connect).  Sounds more like what you want is a retry option which is easy enough to script.

I believe you're trying to make an enhancement suggestion to extend what --ignore-errors does.  If so, what more are you wanting it to do?

@Kevin, your understanding here is incorrect:  rsync bails entire transfers on things that are NOT fatal to the entire transfer, and --ignore-errors overrides this.  I ended up stumbling upon this bug as a result of trying to remediate the behaviour in the case of the following error:

rsync: write failed on "/mnt/PICO3/foo.tbz2": File too large (27)

--ignore-errors does indeed override the fail-through behaviour in this otherwise non-fatal instance.

(Hint: I'm rsyncing to a vfat filesystem ;), and this file is about 4.5G.  In addition to the fact that the --ignore-errors documentation clearly needs revising, this raises two additional, separate bugs pertaining to a) not caring what errno is, and b) the fact that in the spirit of saving bandwidth we should use fallocate(2) unless a --skip-[f]allocate switch (e.g. for compressed destination filesystems) is presented, so we're not transferring data that we could have predicted would get thrown out... and a third for c) --progress tells us the wrong thing when the file can no longer be grown, indicating that the transfer is actually at 100%!)

Slightly correction to my above comment, implying 1-2 more bugs:

- When --ignore-errors is not specified, all subsequent files fail with 'Operation not permitted (1)', which is incorrect, at least at the environment level (the receiver might be emitting this, but not for any earthly reason as it were).

- Using --ignore-errors also does The Wrong Thing:  Files after the problematic file (foo.tbz2 in my above example) are shown by --progress as transferred at increasingly fast speeds, in this case 150-200MB/sec, and the last couple approaching twice that... without stracing this these appear to be roughly the source filesystem read speeds?!

So, --ignore-errors being misdocumented and misimplemented appear to have come as a pair.

(Sorry, more...)

The greatest sin of how --ignore-errors misbehaves in the above case is that the only error REPORTED at the end of the transfer is the one for the oversized file that caused the problem... so a bunch of files are shown as transferred by --progress and yet never were, so perhaps this is --lie-about-errors :)