On Tue, Oct 22, 2013 at 19:23:47 -0700, Paul Eggert wrote:
> There's a longstanding bug in GNU tar in that situation on Solaris,
> with a FIXME for it (there should be no reason to need absolute file
> names, even for incrementals), but the core dump shouldn't occur
Paul,
I noticed that the extrac09.at file's header still contains the
explanatory text left over from the listed03.at that you copied from.
Attached is a patch with my attempt to fill in the correct explanation.
Also, does it make sense to include a mention of "listed03.at" in the
FIXME paragraph, as proposed in the second patch?
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
diff --git a/tests/extrac09.at b/tests/extrac09.at
index bde656f..bff4508 100644
--- a/tests/extrac09.at
+++ b/tests/extrac09.at
@@ -18,10 +18,20 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-# This checks for the --listed-incremental bug reported by J Chapman Flack at
-# http://lists.gnu.org/archive/html/bug-tar/2010-06/msg00000.html
-
-AT_SETUP([no need to save dir with unreadable . and ..])
+# This attempts to cause xgetcwd() to fail, and then checks to see if
+# such failure causes tar to abort even in a case where the results of
+# the call aren't actually needed.
+#
+# (xgetcwd() may fail e.g. on Solaris 10 when "." or ".." are unreadable.
+# On most systems xgetcwd() won't fail even in that situation, but
+# on those systems this test will simply succeed without actually testing
+# anything within tar.)
+#
+# http://lists.gnu.org/archive/html/bug-tar/2010-07/msg00045.html
+#
+# (See also listed03.at .)
+
+AT_SETUP([extracting even when save dir fails])
AT_KEYWORDS([extract extrac09])
AT_TAR_CHECK([
diff --git a/src/misc.c b/src/misc.c
index aecf438..8b8a606 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -288,7 +288,8 @@ normalize_filename (int cdidx, const char *name)
this following approach may lead to situations where the same
file or directory is processed twice under different absolute
paths without that duplication being detected. Perhaps we
- should use dev+ino pairs instead of names? */
+ should use dev+ino pairs instead of names? (See listed03.at for
+ a related test case.) */
const char *cdpath = tar_getcdpath (cdidx);
size_t copylen;
bool need_separator;
