Blame tar-1.14-loneZeroWarning.patch
|
|
3f4a491 |
diff -ruNp tar-1.22.orig/src/list.c tar-1.22/src/list.c
|
|
|
3f4a491 |
--- tar-1.22.orig/src/list.c 2008-10-30 12:10:04.000000000 +0100
|
|
|
3f4a491 |
+++ tar-1.22/src/list.c 2009-03-06 00:03:05.925105425 +0100
|
|
|
3f4a491 |
@@ -136,6 +136,14 @@ read_and (void (*do_something) (void))
|
|
|
c2c695c |
|
|
|
c2c695c |
if (!ignore_zeros_option)
|
|
|
c2c695c |
{
|
|
|
c2c695c |
+ /*
|
|
|
c2c695c |
+ * According to POSIX tar specs, this is wrong, but on the web
|
|
|
c2c695c |
+ * there are some tar specs that can trigger this, and some tar
|
|
|
c2c695c |
+ * implementations create tars according to that spec. For now,
|
|
|
c2c695c |
+ * let's not be pedantic about issuing the warning.
|
|
|
c2c695c |
+ */
|
|
|
c2c695c |
+#if 0
|
|
|
c2c695c |
+
|
|
|
c2c695c |
char buf[UINTMAX_STRSIZE_BOUND];
|
|
|
c2c695c |
|
|
|
c2c695c |
status = read_header (false);
|
|
|
3f4a491 |
@@ -143,6 +151,8 @@ read_and (void (*do_something) (void))
|
|
|
c2c695c |
break;
|
|
|
c2c695c |
WARN ((0, 0, _("A lone zero block at %s"),
|
|
|
c2c695c |
STRINGIFY_BIGINT (current_block_ordinal (), buf)));
|
|
|
c2c695c |
+#endif
|
|
|
3f4a491 |
+ status = read_header (false);
|
|
|
c2c695c |
break;
|
|
|
c2c695c |
}
|
|
|
c2c695c |
status = prev_status;
|