bin/118087: restore complains about "Header with wrong dumpdate"

[Javier Martín Rueda]

>Number:         118087
>Category:       bin
>Synopsis:       restore complains about "Header with wrong dumpdate"
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Nov 16 16:10:03 UTC 2007
>Closed-Date:
>Last-Modified:
>Originator:     Javier Martín Rueda
>Release:        FreeBSD 7.0-BETA2 amd64
>Organization:
DIATEL - Universidad Politécnica de Madrid
>Environment:
FreeBSD rosa.lab.diatel.upm.es 7.0-BETA2 FreeBSD 7.0-BETA2 #0: Fri Nov  2 14:54:38 UTC 2007     root at myers.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

>Description:
In 7.0, restore checks the dumpdate which is recorded in every tape block to validate the tape. I imagine this was added as a fool-proof measure to detect if the operator mixes up the tapes of a multivolume backup.

This brings two problems, as far as I have seen:

1) If you make a backup in 7.0 and then restore it in 7.0, you get a disturbing "Header with wrong dumpdate" message when restore starts, although everything works just fine. After checking the source code, it seems the cause is that restore checks the dumpdate before initializing the variable where it is supposed to be, and therefore the message is spureous.

2) If you make a backup in 6.2 and then restore it in 7.0, you get thousands of "Header with wrong dumpdate" messages. I haven't confirmed it, but I suspect that dump in earlier FreeBSD releases recorded the dumpdate only in the first tape block. As restore in 7.0 checks the dumpdate in every single tape block, we get an error message for every block in the tape.

>How-To-Repeat:
# dump 0aLf /var/tmp/aux.dump /
  ... Usual messages, everything fine ...
# restore -if
Header with wrong dumpdate.
restore >

In 7.0, you only get the above error message.

If you make a backup in 6.2, and try to restore it in 7.0, you will get many more error messages.
>Fix:
I propose this patch. If one of the two dates being compared is zero (that is, uninitialized or unrecorded), then restore will not complain.

Patch attached with submission follows:

--- sbin/restore/tape.c.orig	2007-03-06 09:13:20.000000000 +0100
+++ sbin/restore/tape.c	2007-11-16 16:48:11.000000000 +0100
@@ -1377,7 +1377,7 @@
 	}
 	if (checksum((int *)buf) == FAIL)
 		return (FAIL);
-	if (_time64_to_time(buf->c_date) != dumpdate)
+	if (dumpdate != 0 && buf->c_date != 0 && _time64_to_time(buf->c_date) != dumpdate)
 		fprintf(stderr, "Header with wrong dumpdate.\n");
 	if (Bcvt) {
 		swabst((u_char *)"8l4s1q8l2q17l", (u_char *)buf);


>Release-Note:
>Audit-Trail:
>Unformatted: