Red Hat Bugzilla – Bug 5923
Restore cannot restore files with symlinks.
Last modified: 2008-05-01 11:37:52 EDT
When I try to restore a dump with symlinks in it I get
the following messages for each symlink:
% rpm -qf `which restore`
% gunzip -c ~/GravesLocal.gz | /sbin/restore xf -
/sbin/restore: ./man: cannot create special file: Operation
/sbin/restore: ./mmdf/table/mmdfdbm.db: cannot create
special file: Operation not permitted
It after extracting the files it then thinks it wants
to change tapes on a pipe and aborts, which leaves all
the files with the wrong permissions and wrong ownership.
Restore from another Linux box can successfully restore
the dump file, as can restore on FreeBSD.
This is a bug new in RedHat 6.1; the RedHat 6.0 restore will
restore things fine.
(I also think that this is a fairly severe bug: dump-based backups
cannot be restored easily on RedHat 6.1 machines.)
------- Additional Comments From 11/04/99 08:26 -------
I mailed this to bugzilla, thinking it would get added as a comment,
but didn't. So here goes again.
> + This is a bug new in RedHat 6.1; the RedHat 6.0 restore will
> +restore things fine.
I've just had a quick look - this looks easy enough to fix. A
return was removed in the middle of a switch/case statement, so
the link case was falling through to the special file case.
The mistake seems to be in dump-0.4b4-alpha.patch.
--- dump-0.4b4/restore/tape.c.redhat Thu Oct 21 11:51:34 1999
+++ dump-0.4b4/restore/tape.c Thu Oct 21 11:52:02 1999
@@ -576,6 +576,7 @@
if (linkit(lnkbuf, name, SYMLINK) == FAIL)
(void) chown(name, luid, lgid);
*** Bug 4815 has been marked as a duplicate of this bug. ***
Fixed in the current dump in Raw Hide.
*** Bug 6950 has been marked as a duplicate of this bug. ***