On Wed, Jan 6, 2016 at 6:58 AM, Pavel Raiskup <[email protected]> wrote: > Anyways, it would be fine to have rather a better option for it, something > similar to "--warning", but the effect would be > dont-switch-to-nonzero-status.
I agree. If it's an option to implement a new option, then that would be great. Alternatively, see below. > Other than that; If the file have shrunk/grew, it _is_ serious issue from > the consistency POV! And returning non-zero status is IMO really worth. > I can imagine that in really *rare* situation you can expect that the > archived file may be restored a safe way. And to me, --ignore-failed-read > ignores way too much (orthogonal) situations. I'm the author of vbackup, a tool for easing system backups and one of the methods used is tar. The tool attempts to detect whether tar has failed or not. I can tell you from my experience that it is practically impossible to setup automated backups of a running system without such an error, because there are always files that change and for which you may have no interest. I understand that this may result in the files not being backed up properly, but there needs to be an option that ignores single file errors. Otherwise it's impossible to auto-detect more critical failures (e.g. out of space). This bug report came as a request from exactly that: A user of vbackup reporting tar backups failing because files were changing underneath. My workaround at this point is to ignore exit code 1 from tar. If you think that this is a better option then can you consider documenting exit codes 1 and 2 in the man page? I.e. to document PAXEXIT_DIFFERS and PAXEXIT_FAILURE, so that a user of tar can chose to ignore PAXEXIT_DIFFERS. Thanks, Stefanos
