bin/121502: option -P appears to be broken in restore(8) since FreeBSD 6.3 (regression)

[Derek Kuliński]

The following reply was made to PR bin/121502; it has been noted by GNATS.

From: =?utf-8?Q?Derek_Kuli=C5=84ski?= <takeda at takeda.tk>
To: Jaakko Heinonen <jh at saunalahti.fi>
Cc: bug-followup at FreeBSD.org
Subject: Re: bin/121502: option -P appears to be broken in restore(8) since FreeBSD 6.3 (regression)
Date: Mon, 24 Mar 2008 14:57:24 -0700

 One more thing, before patching, there's a different behavior:
 [chinatsu]:/usr/src/sbin/restore# restore -xNP "/usr/local/bin/gzip -dc /backup/dump.chinatsu.1.1.2008-03-20.var.gz"
 Header with wrong dumpdate.
 You have not read any tapes yet.
 If you are extracting just a few files, start with the last volume
 and work towards the first; restore can quickly skip tapes that
 have no further files to extract. Otherwise, begin with volume 1.
 Specify next volume #: 1
 set owner/mode for '.'? [yn] n
 [chinatsu]:/usr/src/sbin/restore# restore -xNP "/usr/bin/gzip -dc /backup/dump.chinatsu.1.1.2008-03-20.var.gz"
 Header with wrong dumpdate.
 You have not read any tapes yet.
 If you are extracting just a few files, start with the last volume
 and work towards the first; restore can quickly skip tapes that
 have no further files to extract. Otherwise, begin with volume 1.
 Specify next volume #: 1
 unknown tape header type 16843009
 abort? [yn] n
 Mount tape volume 2
 Enter ``none'' if there are no more tapes
 otherwise enter tape name (default: /usr/bin/gzip -dc /backup/dump.chinatsu.1.1.2008-03-20.var.gz)
 
 When I use it with gzip from ports, it behaves pretty much like it did
 in the past (asking for the volume number) I'm not sure if that was
 correct or not. According to manpage, the RESTORE_VOLUME variable
 supposed to be defined each time restore is called.
 
 -- 
 Derek