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

[Jaakko Heinonen]

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

From: Jaakko Heinonen <jh at saunalahti.fi>
To: Derek =?utf-8?B?S3VsacWEc2tp?= <takeda at takeda.tk>
Cc: bug-followup at FreeBSD.org, green at FreeBSD.org
Subject: Re: bin/121502: option -P appears to be broken in restore(8) since
	FreeBSD 6.3 (regression)
Date: Tue, 25 Mar 2008 11:10:20 +0200

 Hi,
 
 On 2008-03-24, Derek Kuliński wrote:
 > One more thing, before patching, there's a different behavior:
 
 > When I use it with gzip from ports, it behaves pretty much like it did
 > in the past (asking for the volume number)
 
 Looking at the source code the behavior after patching might be
 correct:
 
 (tape.c)
 308          if (pipein) {
 309                  if (nextvol != 1) {
 310                          panic("Changing volumes on pipe input?\n");
 311                          /* Avoid looping if we couldn't ask the user. */
 312                          if (yflag || ferror(terminal) || feof(terminal))
 313                                  done(1);
 314                  }
 315                  if (volno == 1)
 316                          return;
 317                  if (pipecmdin) {
 318                          closemt();
 319                          goto getpipecmdhdr;
 320                  }
 321                  goto gethdr;
 322          }
 
 In unpatched restore(8) pipein and pipecmdin are never set at the same time.
 Thus the code never reaches line 319 which causes restore(8) to skip "Specify
 next volume #: " prompt. (When volno == 1 it's already skipped at line
 316.) However looking at it more carefully the goto on line 319 can't be
 correct either because then newvol will be uninitialized at line 409.
 
 Seems that -P has been broken since it's introduction to tape.c revision
 1.39. I have cc'd green@ who committed the revision 1.39. He should know
 what the intended behavior is. (Please see
 http://www.freebsd.org/cgi/query-pr.cgi?pr=121502 what we have found out
 so far.)
 
 -- 
 Jaakko