karl@sugar.UUCP (Karl Lehenbauer) (03/04/88)
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
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/08/88)
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
mrspock@hubcap.UUCP (Steve Benz) (03/09/88)
From article <9824@steinmetz.steinmetz.UUCP>, by davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr): > 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... > 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. We had a situation where cpio was somehow causing a bug in the pipe drivers to show up. This was with the NCR Tower & Tower XP. I wasn't the one who tracked the problem to being a kernel bug, rather the one who wrote the application which ran at the other end of the pipe. I can't say too much about it, because it was a long time ago, and I was only in my third month of Unix programming at the time. Suffice to say that this problem may be something created by AT&T a long time ago (> 3 years.) - Steve ...!gatech!hubcap!mrspock mrspock@hubcap.clemson.edu
karl@sugar.UUCP (Karl Lehenbauer) (03/14/88)
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
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/15/88)
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" -meboykin@encore.UUCP (Joe Boykin) (03/17/88)
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
les@chinet.UUCP (Leslie Mikesell) (03/19/88)
>> >>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
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/20/88)
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.
friedl@vsi.UUCP (Stephen J. Friedl) (03/20/88)
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