On Sun, Sep 28, 2014 at 01:49:52AM +0200, Steinar H. Gunderson wrote:
> I've attached a simple patch to fix this; it doesn't give access to all the
> other fields, but at least it fixes th_get_pathname() (which seems to be
> pretty much the only place the prefix field is actually interpreted) so that
> it does not return these bogus paths.
I'm sorry, this wasn't well enough tested; it only works with -H oldgnu,
not --incremental (which was what I intended to fix), so it's all wrong,
and the logic is inverted to boot. This one should be much better;
tested with a regular tarball, -H oldgnu and -g.
/* Steinar */
--
Homepage: http://www.sesse.net/
Index: libtar-1.2.20/lib/decode.c
===================================================================
--- libtar-1.2.20.orig/lib/decode.c
+++ libtar-1.2.20/lib/decode.c
@@ -69,7 +69,14 @@ th_get_pathname(TAR *t)
return NULL;
}
- if (t->th_buf.prefix[0] == '\0')
+ /*
+ * Old GNU headers (also used by newer GNU tar when doing incremental
+ * dumps) use the POSIX prefix field for many other things, such as
+ * mtime and ctime. New-style GNU headers don't, but also don't use the
+ * POSIX prefix field. Thus, only honor the prefix field if the archive
+ * is actually a POSIX archive. This is the same logic as GNU tar uses.
+ */
+ if (strcmp(t->th_buf.magic, TMAGIC) != 0 || t->th_buf.prefix[0] == '\0')
{
sprintf(t->th_pathname, "%.100s", t->th_buf.name);
}
