bin/121502: option -P appears to be broken in "restore" since
takeda at takeda.tk
Sat Mar 8 20:10:02 UTC 2008
>Synopsis: option -P appears to be broken in "restore" since FreeBSD 6.3
>Arrival-Date: Sat Mar 08 20:10:01 UTC 2008
>Originator: Derek Kulinski
>Release: FreeBSD 6.3-RELEASE-p1 i386
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
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
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
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)
More information about the freebsd-bugs