home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / sysv386 / 13819 < prev    next >
Encoding:
Text File  |  1992-08-30  |  3.0 KB  |  69 lines
  1. Newsgroups: comp.unix.sysv386
  2. Path: sparky!uunet!mcsun!Germany.EU.net!math.fu-berlin.de!umn.edu!dialup-slip-1-20.gw.umn.edu!user
  3. From: sells@cs.umn.edu (Chris Sells)
  4. Subject: Re: cpio one file at a time?
  5. Message-ID: <sells-300891220405@dialup-slip-1-20.gw.umn.edu>
  6. Followup-To: comp.unix.sysv386
  7. Sender: news@news2.cis.umn.edu (Usenet News Administration)
  8. Nntp-Posting-Host: dialup-slip-1-20.gw.umn.edu
  9. Organization: Spanlink Communications
  10. References: <sells-290891105149@dialup-slip-1-31.gw.umn.edu> <1992Aug31.011929.9632@unislc.uucp>
  11. Date: Mon, 31 Aug 1992 03:12:42 GMT
  12. Lines: 55
  13.  
  14. In article <1992Aug31.011929.9632@unislc.uucp>, dold@unislc.uucp (Clarence
  15. Dold) wrote:
  16. > 
  17. > From article <sells-290891105149@dialup-slip-1-31.gw.umn.edu>, by sells@cs.umn.edu (Chris Sells):
  18. > 
  19. > > The 'mv' was only an example. I'll be performing multiple operations on
  20. > > each file and I need to be able to do it before the next file is loaded.
  21. > > BTW, what's pax?
  22. > 
  23. > Methinks that a named pipe fits into this scheme somewhere.
  24. > I might be inclined to read directly from the tape to a file, perhaps via my
  25. > code, or dd, where the file on disk is a named pipe that would be a raw
  26. > cpio dataset.  Then the "special" process would read from the raw data, and
  27. > pipe to cpio.  While monitoring the files that cpio is creating and filling
  28. > (by some undescribed method), the "special" process would stop feeding data
  29. > down the pipe to cpio until the manipulation was done.  Then the data feed
  30. > would resume into cpio.
  31. > The named pipe would be some system determined maximum size on disk, I think
  32. > 5K.  The tape coming in would stop while the pipe was at its maximum size,
  33. > and feed when the named pipe is drained.  The "special" process would act as
  34. > a throttle, controlling the data rate into cpio.  Without figuring out how
  35. > to monitor the internals of a cpio archive, I might do something as crude as
  36. > a cpio -it to find the file names on disk, storing the names, then start in
  37. > earnest, watching for each to be created (or modified), as an indication that 
  38. > the previous one was fully restored.
  39. > Named pipes are created with "mknod foobar p"
  40. > 
  41. > -- 
  42. > ---
  43. > Clarence A Dold - dold@unislc.slc.Unisys.COM
  44. >                ...pyramid!ctnews!tsmiti!dold
  45.  
  46. You mean, something like this?
  47.  
  48. mknod foo p                      # make input pipe
  49. mknod bar p                      # make output pipe
  50. pr_pid=`pipe_reader foo bar &`   # start pipe_reader and keep pid
  51.  
  52. dd if=/dev/rdsk/tape0 >foo &     # start data dump
  53.  
  54. cat bar | cpio -iv |             # dump 'throttled' data into cpio
  55. while read file                  # for each file
  56. do
  57.    kill $pr_pid                  # signal pipe_reader to pause
  58.    handle $file                  # handle file while cpio paused
  59.    kill $pr_pid                  # signal pipe_reader to continue
  60. done
  61.  
  62. Thanx, I'm not sure how well this would work, but it's the best (read
  63. 'only) idea I've gotten so far.
  64. +-------------------------+
  65. | Chris Sells             |
  66. | Spanlink Communications |
  67. | sells@cs.umn.edu        |
  68. +-------------------------+
  69.