EISDIR Check and Doc Fix.

[Ralph Corderoy]

Hi,

I'm investigating using GNU tar for incremental back-ups and have been
using 1.13.25 after I got puzzling behaviour with the latest non-alpha
release of 1.13.19.

Under Linux unlink("dir") returns EISDIR and has done for quite a while.
I don't know why they decided to deviate, but unlink(2) documents it and
a web search shows it's prevalent.

This causes problems with src/misc.c:/^remove_any_file when
(!we_are_root) means the first unlink("dir") fails but errno isn't EPERM
as expected for a directory.  The end result is tar giving an error and
its exit status indicating failure.  I can give a test script that
triggers this if you require.

Here's a possible patch.

diff -ruN tar-1.13.25/src/misc.c tar-1.13.25.new/src/misc.c
--- tar-1.13.25/src/misc.c      Mon Aug 27 00:14:26 2001
+++ tar-1.13.25.new/src/misc.c  Tue Jun  4 18:16:41 2002
@@ -259,7 +259,7 @@
     {
       if (unlink (path) == 0)
        return 1;
-      if (errno != EPERM)
+      if (errno != EPERM && errno != EISDIR)
        return 0;
     }
 

Anyone know if work has been going on in the --listed-incremental area
between 1.13.19 and 1.13.25?  I was wondering which I should stick to
for my backups.

The documentation in the whole incremental area obviously needs work;
there seems to be two lots of text in there on the same subject matter.
One bit seems plain wrong from reading the source, and I thought
something else needed spelling out explicitly.  I think it is worth
improving the documentation a little in the meantime.

diff -ruN tar-1.13.25.orig/doc/tar.texi tar-1.13.25/doc/tar.texi
--- tar-1.13.25.orig/doc/tar.texi       Wed Sep 26 19:46:09 2001
+++ tar-1.13.25/doc/tar.texi    Tue Jun  4 22:25:44 2002
@@ -4767,9 +4767,6 @@
 be archived are determined, but before the new archive is actually
 created.
 
address@hidden @command{tar} actually writes the file twice: once before the 
data
-and written, and once after.
-
 @node Inc Dumps
 @section Using @command{tar} to Perform Incremental Dumps
 @UNREVISED
@@ -4883,6 +4880,11 @@
 to comparing directories; this is fairly gross, but there does not seem
 to be a better way to go.
 
address@hidden doesn't access @var{snapshot-file} when @value{op-create}
+or @value{op-list} are specified, but the @value{op-listed-incremental}
+option must still be given.  A non-existant @var{snapshot-file} or
+place-holder can thus be specified, e.g. @file{/dev/null}.
+
 @FIXME{this section needs to be written}
 
 @node Backup Levels

I'd welcome any feedback on these patches.

Cheers,


Ralph.