Re: EISDIR Check and Doc Fix.

[Ralph Corderoy]

Hi,

Paul Eggert <address@hidden> wrote:
> Thanks for the doc patch.  Yes, the EISDIR patch is needed.  I blame
> the bug on the new POSIX standard.  See:
>
> http://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-group-l&id=3740

My original mail to address@hidden, picked up by Paul, won't make it to
gnu.utils.bug so for completeness here's the original post.

    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.