[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EISDIR Check and Doc Fix.
From: |
Ralph Corderoy |
Subject: |
Re: EISDIR Check and Doc Fix. |
Date: |
Wed, 12 Jun 2002 10:36:09 GMT |
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.