Xref: utzoo comp.bugs.sys5:346 comp.unix.microport:166 comp.unix.xenix:1631
Path: utzoo!mnetor!uunet!husc6!bbn!rochester!cornell!batcomputer!itsgw!steinmetz!davidsen
From: davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr)
Newsgroups: comp.bugs.sys5,comp.unix.microport,comp.unix.xenix
Subject: Re: FIFOs break tar, others
Message-ID: <9824@steinmetz.steinmetz.UUCP>
Date: 7 Mar 88 20:12:05 GMT
References: <1512@sugar.UUCP>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 35
Cc: kane


In article <1512@sugar.UUCP> karl@sugar.UUCP (Karl Lehenbauer) writes:
| Tar will hang when it tries to open FIFOs.  Cpio and even 'cp' will
| too, but the find command that is typically piped into 'cpio -o' can 
| do a '-type f' so cpio'll never see the FIFO and it could be argued
| that 'cp' should not have to look at file types.  Well and good.

  I tried this on Xenix (286 and 386), SunOS, Ultrix, and a 3B2. This is
what I found.
	1) none of the systems hung backing up pipes with cpio
	2) all of the systems flagged the pipe correctly in the output
	3) all except Ultrix restored the pipe correctly.

  Outside of reporting the bug in Ultrix, I think it would be useful for
people to report their experiences, so that we get a feel for which
systems exhibit the problem you mention.

  I did this (but I'm retyping by hand):
	mkdir TeMp
	cd TeMp
	/etc/mknod fifo p; date >x; ls -l
	ls > files
	cpio -ov < files > cpio.out
	cpio -itv < cpio.out
	rm `cat files`
	cpio -idmlv < cpio.out
	ls -l
	# then...
	cd ..; rm -rf TeMp

  I sure do agree that tar doesn't quite do the job (again, on the
systems I've tried), but except for Ultrix I haven't seen a failure.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me