home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / admin / 6632 < prev    next >
Encoding:
Text File  |  1992-12-14  |  2.4 KB  |  56 lines
  1. Newsgroups: comp.unix.admin
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!agate!doc.ic.ac.uk!cc.ic.ac.uk!imperial.ac.uk!vulture
  3. From: vulture@imperial.ac.uk (Thomas Sippel - Dau)
  4. Subject: Re: How to determine the # of files per tape?
  5. Message-ID: <1992Dec14.193835.14513@cc.ic.ac.uk>
  6. Sender: vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau)
  7. Nntp-Posting-Host: cscgc
  8. Reply-To: cmaae47@imperial.ac.uk
  9. Organization: Imperial College of Science, Technology and Medicine
  10. References: <1992Dec11.180114.21986@nsisrv.gsfc.nasa.gov>
  11. Date: Mon, 14 Dec 92 19:38:34 GMT
  12. Lines: 42
  13.  
  14. In article <1992Dec11.180114.21986@nsisrv.gsfc.nasa.gov>, markb@news.gsfc.nasa.gov (Mark R. Baith) writes:
  15. - 
  16. - Does anyone have an idea for determining the number of files on a
  17. - foreign data tape ? 
  18. - 
  19. - (Note: Foreign in the sense that the tape is not a standard UNIX
  20. - tar or backup tape...the tape simply contains data files)
  21.  
  22. You need to define "file" more clearly. If it cam from VMS and was 
  23. written in VMS backup form, you have two definitions of file: 
  24.  
  25.     o  file on the tape, I.e. a contiguous sequence of fixed length
  26.        block ended by a tape mark or file mark constitutes a "save set"
  27.  
  28.     o  file as the user sees it, with each of the seve sets containing
  29.        one of more "files", with format, name, owner and access information
  30.        for the file
  31.  
  32. Each of these user files could, of course, have been a save set ...
  33. In any case, if its a VMS backup tape, you are almost stuffed, as the only
  34. known way to read them reliably is to buy a VMS machine to do it.
  35.  
  36. You could start by counting file marks by (on ***x) issueing a read() with 
  37. an appropriate buffer size and count the number of zero length blocks,
  38. or however else your system indicates having found a file mark.
  39.  
  40. No, I will not define "appropriate" more clearly, try 1 Gigabyte of read()
  41. buffer, that shouldcover most cases ...
  42.  
  43. Be sure not to mistake parity errors at the beginning of a block for 
  44. file marks ...
  45.  
  46. In short, unless you know more about the tape or use your initiative,
  47. it is pretty hopeless.
  48.  
  49.                                   Thomas
  50. -- 
  51. *** This is the operative statement, all previous statements are inoperative.
  52. *   email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
  53. *   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
  54. *   snail: Imperial College of Science, Technology and Medicine
  55. *   The Center for Computing Services, Kensington SW7 2BX, Great Britain
  56.