Bug 4176 - restore gets confused when run over pipe "Changing volumes on pipe input"
Summary: restore gets confused when run over pipe "Changing volumes on pipe input"
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 2.2-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Matt Jacob
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 1997-07-27 03:10 UTC by Charlie Root
Modified: 2002-03-01 21:33 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Charlie Root 1997-07-27 03:10:01 UTC
With the following command line:

( dump 0f - /dev/sd0s1x | ssh -c none newmachine 'cd /usr/old-katiska-usr && restore -xvf -' ) | & tee /tmp/logfile

at the end of input, when restore is supposed to start setting the modes
and owners of the files, this appears, endlessly:

abort? [yn] Changing volumes on pipe input?
abort? [yn] Changing volumes on pipe input?
abort? [yn] Changing volumes on pipe input?
abort? [yn] Changing volumes on pipe input?
abort? [yn] Changing volumes on pipe input?
abort? [yn] Changing volumes on pipe input?
abort? [yn] Changing volumes on pipe input?
abort? [yn] Changing volumes on pipe input?

All the data has already been copied at this point, and dump has reported 
dump done.  The unfortunate effect is that owners are broken.

I do not seem to be able to produce this on small input, but it happens
repeatably when copying 4G over a network.

Fix: 

I do not know, but looks like something is missing somewhere.  It could also
be a problem in ssh, maybe it drops data at the end of transfer and
restore thinks early eof to be a volume change ?
How-To-Repeat: 
Use the above line with large enough filesystem.
Comment 1 Heikki Suonsivu 1997-07-28 04:54:24 UTC
   Synopsis:       restore gets confused when run over pipe "Changing volumes on pipe input"

   With the following command line:

   ( dump 0f - /dev/sd0s1x | ssh -c none newmachine 'cd /usr/old-katiska-usr && restore -xvf -' ) | & tee /tmp/logfile

   at the end of input, when restore is supposed to start setting the modes
   and owners of the files, this appears, endlessly:

   abort? [yn] Changing volumes on pipe input?
   abort? [yn] Changing volumes on pipe input?
   abort? [yn] Changing volumes on pipe input?
...

   I do not seem to be able to produce this on small input, but it happens
   repeatably when copying 4G over a network.

Copying on a local disk with command

dump 0f - /usr | (cd /mnt; restore xvf -)

also fails, but in this case tty is connected so it keeps asking abort?
[yn] forever.

I worked around by copying the stuff with tar, but dump/restore would be a
little bit faster.

I did not try interactive mode; that might work better if you manage to get
into restore prompt and use setmodes command.

This may be very serious problem it this means that recovering large
backups from tape is impossible.

-- 
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@clinet.fi
mobile +358-40-5519679 work +358-9-43542270 fax -4555276
Comment 2 Mike Barcroft freebsd_committer freebsd_triage 2001-07-22 07:02:24 UTC
State Changed
From-To: open->feedback


Does this problem still occur in newer versions of FreeBSD, 
such as 4.3-RELEASE?
Comment 3 mreimer 2001-08-17 19:43:41 UTC
It just happened to me doing a local dump/restore (dump 0af - /home |
restore xf -).

Matt
Comment 4 Kris Kennaway freebsd_committer freebsd_triage 2001-09-08 09:36:14 UTC
State Changed
From-To: feedback->suspended

Apparently still a problem.  Suspending awaiting fix and 
committer.
Comment 5 wilko freebsd_committer freebsd_triage 2001-11-24 11:47:27 UTC
Responsible Changed
From-To: freebsd-bugs->mjacob

Matt, I saw you did some work on dump/restore PRs. Do you have a clue 
to offer for this one?
Comment 6 iedowse freebsd_committer freebsd_triage 2002-03-01 21:32:58 UTC
State Changed
From-To: suspended->closed


Fixed in both -CURRENT and -STABLE.