home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0127.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  2.2 KB
  1. From:  news@ira.uka.de
  2.  
  3. --- archives and tapes ---
  4.  
  5. First, I have to admit that I haven't read the latest standard's version,
  6. but I do have strong feelings about data archives and transport.
  7.  
  8. Both tar and cpio are highly deficient for properly moving information
  9. out and in. The first blunder of all is the limited format that does not
  10. take care of long file names. There is a NAMSIZ parameter, so for heaven's
  11. sake reserve sufficient space in the file descriptor of such a transport
  12. archive! That's so fundamental that I will only talk about one other equally
  13. nasty point about these formats, missing archive and volume labelling.
  14.  
  15. Next, you have to realize that both tar and cpio already do arrange data
  16. in suitable chunks for transfer ('tar' reads 'tape archive'!). There is
  17. no reason in the world why an ANSI tape file shall not be the envelope
  18. for a UNIX-type archive. On the contrary, this will finally, after all
  19. these years offer data labelling, both on the archive and on the tape
  20. volumes. It is unbelievable that today, 1990, i have to look at a piece of
  21. paper with my tar tape, which tells me about a number of archives on the
  22. same medium and their position. Additionally, the ANSI tar standard
  23. provides multi-volume data sets, so yet another stumbling stone can be
  24. forgotten, if we only wrap tar' and cpio' archives in ANSI tape structures
  25. (where tar' and cpio' are improved versions of tar and cpio).
  26.  
  27. Then, a point often forgotten: There is a real need to select, duplicate,
  28. store data from some external medium (tape) on a different type of machine
  29. than the one the tape is written on / to be read.  The proposal above will
  30. make that an easy and safe operation, what cannot be claimed today. (Today,
  31. ypou just have to have a guru around who knows alls kinds of different
  32. machines and how they mix).
  33.  
  34. Finally: Yes, we do move archives across networks, but for most substantial
  35. transfers of data in and out of our machines there is no adequate replacement
  36. for sequential magnetic media. Posix has to take that into account, or we
  37. will be burdened with those problems of today.
  38.  
  39. Karl Kleine
  40. FZI Forschungszentrum Informatik, Karlsruhe, West-Germany;  kleine@fzi.uka.de
  41.  
  42.  
  43.  
  44. Volume-Number: Volume 20, Number 125
  45.  
  46.