Re: [Bug-tar] error handling and exit code (patch for tar-1.20/1.21)

[Solar Designer]

Sergey,

My installs of tar-1.22.90-owl1 have been running just as well as those
of tar-1.20-owl4 did so far.  All of them are doing incremental backups.

However, I've learned of a few issues:

In the testsuite, test 26 reliably fails when running with umask 077.

 26: restoring mode on existing directory            FAILED (extrac08.at:36)

In the diffs, I see:

-755
+700

Maybe the test needs to use the "p" option or maybe it needs to use
umask 022?  This depends on what exactly it is meant to test.

Then, test 38 fails intermittently.  It appears to be more likely to fail
during the first build on a system than during subsequent rebuilds.  In
the diffs, I see:

-tar: dir/file1: File removed before we read it
+tar: dir/file1: file changed as we read it

This must be some sort of a race condition.  I'm not sure if it needs to
be fixed in tar itself or in the test - I did not look into it.

Finally, as it relates to the tests, it was reported to me that test 12
fails on some systems (where all other tests pass):

 12: transforming hard links on create               FAILED (xform-h.at:39)

I am unable to reproduce this myself, and I have no diffs from the
reporter (yet).  Sorry for the lack of info on this one.

Now to a real issue:

On one of the systems still running 1.20-owl4, I just got tar to exit
with TAREXIT_FAILURE upon getting this error:

tar: ./home/clients/databases/b_main: Cannot savedir: No such file or directory

The directory above was removed while tar was running.  All other error
messages from tar were usual (some "File removed before we read it" and
"socket ignored" ones), so I suspect that only the one I quoted above
was the reason for the TAREXIT_FAILURE exit code.  I've just upgraded
that system to 1.22.90-owl1, but I don't expect it to make a difference
(it might take months until the issue shows up again, though).

In 1.22.90's src/incremen.c: scan_directory() we have this:

  char *dirp = savedir (dir);   /* for scanning directory */
[...]
  if (! dirp)
    savedir_error (dir);

Perhaps we need to patch this in our usual way?

Maybe we also need to check for other calls to savedir().

Thanks,

Alexander