🚀 go-pugleaf

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

In article <9824@steinmetz.steinmetz.UUCP>, davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) writes:
>   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.

OK, sorry.  Since I found the problem on both my Unix system at home and
the Xenix system at work, I assumed that it was more widespread than it
apparently is.  The bug appears in Microport System V/286 and on Xenix
as supplied by Intel for the Intel 310 multibus '286 box.
-- 
"Weekends were made for programming."  -me
..!uunet!nuchat!sugar!karl, Unix BBS (713) 438-5018

  Several people have told me that pipes can cause trouble with cpio if
they are open. I have not been able to cause that behavior, but I don't
doubt it for a moment. I repeated my tests as follows, without failure.
	/etc/mknode fifo p	# create the pipe
	sleep 180 > fifo	# get it going
	ls | cpio -ov > /tmp/x$$ # try a dump

  Thanks to several who clarified this.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

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.
>
>tar, unfortunately, cannot be told to ignore or to properly "copy" FIFOs.
>-- 
>"Lack of skill dictates economy of style." - Joey Ramone
>..!uunet!nuchat!sugar!karl, Unix BBS (713) 438-5018

The fix to tar is easy, so easy that I posted a fix to this a long time ago!

Basically, one of the first things done in the routine 'putfile' is a 'stat'
of the file you're going to write to tape.  The simple change is to put some
code int which looks like this:

	if((stbuf.st_mode & S_IFMT) == S_IFIFO)
		return;

Another version of tar which I've seen doesn't do a 'stat' first, but
does an open.  On this version I added the O_NDELAY flag and put in
similar code.

----

Joe Boykin
Encore Computer Corp

UUCP: encore!boykin
ARPA: boykin@multimax.arpa

>>
>>tar, unfortunately, cannot be told to ignore or to properly "copy" FIFOs.
>>-- 
>
>Another version of tar which I've seen doesn't do a 'stat' first, but
>does an open.  On this version I added the O_NDELAY flag and put in
>similar code.
>
Don't forget that reading from a FIFO deletes the data.  Thus if you let
tar or cpio read them, some other process is going to lose its input.
Note also that the blocking effect only happens when no process has the
FIFO open for write access.  If there is an active process reading the
FIFO (the typical use being to communicate with some background server
process), the blocking can be avoided by having that process open the
FIFO read/write even though it only intends to read. (Of course its own
reads become non-blocking also..).

  Les Mikesell

In article <3776@chinet.UUCP> les@chinet.UUCP (Leslie Mikesell) writes:
>Don't forget that reading from a FIFO deletes the data.  Thus if you let
>tar or cpio read them, some other process is going to lose its input.

Such archive programs should treat FIFOs the same way as symbolic links
or device special files, namely record information about them but not
attempt to archive their contents.

In article <7478@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <3776@chinet.UUCP> les@chinet.UUCP (Leslie Mikesell) writes:
> >Don't forget that reading from a FIFO deletes the data.  Thus if you let
> >tar or cpio read them, some other process is going to lose its input.
> 
> Such archive programs should treat FIFOs the same way as symbolic links
> or device special files, namely record information about them but not
> attempt to archive their contents.

Sys V fsck(1M) complains about some FIFOs -- is their any good
reason for this?  The bummer is that it causes a laxness about
POSSIBLE FILE SIZE ERRORS ("Oh, that's just a FIFO, don't worry
about it") and real problems are missed.

-- 
Steve Friedl      friedl@vsi.com       *Hi Mom*
{uunet, attmail, ihnp4!amdcad!uport}!vsi!friedl