[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
EISDIR Check and Doc Fix.
From: |
Ralph Corderoy |
Subject: |
EISDIR Check and Doc Fix. |
Date: |
Tue, 04 Jun 2002 22:46:18 +0100 |
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.
- EISDIR Check and Doc Fix.,
Ralph Corderoy <=