why not keep going?

dean gaudet dean-list-rdiff-backup@arctic.org
Fri, 17 May 2002 17:17:29 -0700 (PDT)


On Fri, 17 May 2002, Ben Escoto wrote:

> I am trying to fix these issues for the next version, and do b) in the
> cases you mention.  My thought before was to check for various
> specific errors (as in various kinds of IOError), keep going if the
> error was recognized as one it made sense to keep going from, and
> abort otherwise.
>
>     But it seems hard to recognize all these errors, which may
> different from system to system, so now I think it makes more sense to
> do it the opposite way, and keep going unless an error is recognized
> as one we should stop because of.

in the case of opening a file for reading, gnu tar treats ENOENT as a
warning, and continues the backup.  if --ignore-failed-read is set, then
it will continue past any open() for read errors, otherwise it stops.

generally in most cases gnu tar attempts to stop unless it's in a well
known set of error codes.  it doesn't appear to have too many cases either
-- i see uses of ENOENT, EEXIST, EPERM, ENOTDIR, ENOTEMPTY, and EINTR.

gnu cpio appears to use the same set of errnos -- with an additional EROFS
test (which it looks for after utime() to avoid complaining when its
trying to restore atime while reading files).

there are uses of ENOSPC, EIO, and ENXIO in both tar and cpio -- but seem
to be mostly related to tape manipulation.  ENOSPC seems like something
you'd want to stop on for sure :)

i didn't see any other new errnos to consider in rsync source.

if you decide to go with "continue unless we know for sure it's fatal"
approach, you might want to put in an error counter -- and consinder 100
otherwise unknown errors to be fatal regardless.

-dean