>Number:         30365
>Category:       bin
>Synopsis:       restore should wait for EOF on it's input
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 29 11:09:00 +0000 2005
>Originator:     Havard Eidnes
>Release:        NetBSD 2.0_STABLE
>Organization:
	Unorganized, Inc.
>Environment:
System: NetBSD stegg.urc.uninett.no 2.0_STABLE NetBSD 2.0_STABLE (STEGG.MP) #0: Sun May 15 19:16:41 CEST 2005  he@stegg.urc.uninett.no:/usr/obj/sys/arch/i386/compile.i386/STEGG.MP i386
Architecture: i386
Machine: i386
>Description:
	I recently transported some data from one disk to a new
	(larger) one, by doing

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

	The end of the output looked like this:

  DUMP: 96.98% done, finished in 0:21
  DUMP: 97.80% done, finished in 0:15
  DUMP: 98.58% done, finished in 0:10
  DUMP: 99.74% done, finished in 0:01
  DUMP: 69723972 tape blocks
  DUMP: Volume 1 completed at: Sat May 28 00:08:34 2005
  DUMP: Volume 1 took 11:57:10
  DUMP: Volume 1 transfer rate: 1620 KB/s
  DUMP: Date of this level 0 dump: Fri May 27 12:09:02 2005
  DUMP: Date this dump completed:  Sat May 28 00:08:34 2005
  DUMP: Average transfer rate: 1620 KB/s
  DUMP: Broken pipe
  DUMP: The ENTIRE dump is aborted.

	Now, in this case it has actually already done it's job, and
	restore appears to be content with the result (no complaint
	from it, and it left a restoresymtable in the target
	directory), but I suspect that if I had used the "-u" option
	to dump, the /etc/dumpdates file would not have been updated.

	I suspect that restore is exiting before it has received an
	EOF on it's input file, and that is probably what is causing
	dump heartburn.

>How-To-Repeat:
	See above.

>Fix:
	Sorry, none supplied.