bin/121502: option -P appears to be broken in "restore" since FreeBSD 6.3

[Derek Kulinski]

>Number:         121502
>Category:       bin
>Synopsis:       option -P appears to be broken in "restore" since FreeBSD 6.3
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar 08 20:10:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     Derek Kulinski
>Release:        FreeBSD 6.3-RELEASE-p1 i386
>Organization:
none
>Environment:
System: FreeBSD chinatsu.takeda.tk 6.3-RELEASE-p1 FreeBSD 6.3-RELEASE-p1 #1: Sun Feb 17 18:52:39 PST 2008 root at chinatsu.takeda.tk:/usr/obj/usr/src/sys/CHINATSU i386


>Description:
	I wrote a simple shell script in the past that mounts remote filesystem, does the backup, and then checks if
	filesystem was dumped correctly.
	After upgrade to FreeBSD 6.3 (from 6.2) the script started to warn about errors in the backup files.
	According to fsck the filesystem appears to be fine.
	After futher investigation it turns out that the option -P is a problem:

	[chinatsu]:/root# gzcat /backup/dump.chinatsu.3.5.2008-03-08.var.gz | restore -xNf -
	set owner/mode for '.'? [yn] n
	[chinatsu]:/root# restore -xNP "gzcat /backup/dump.chinatsu.3.5.2008-03-08.var.gz"
	unknown tape header type 0
	abort? [yn] n
	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
	not at beginning of a file
	abort? [yn] n
	Segmentation fault
	Exit 139
	
>How-To-Repeat:
	The way my backup is done (I don't think this actually matters) is as follows:
	mksnap_ffs /usr /usr/.snap/backup
	dump -0 -auh 0 -f - /usr/.snap/backup | gzip -6 -c > /backup/backup.dump
	rm /usr/.snap/backup
>Fix:
	My original command with option -P was as follows:
	(echo 1; echo n) | restore -xNP "gzcat /backup/backup.dump"
	Using pipe gets rid of the problem, unfortunately, for each backup the script
	will halt and wait for user input:
	set owner/mode for '.'? [yn]

	I don't know about any workaround for that (option -y doesn't seem to apply here)

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