home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / std / unix / 349 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  3.6 KB
  1. Path: sparky!uunet!uunet!not-for-mail
  2. From: peter@ferranti.com (Peter da Silva)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: Your chance to contribute to new POSIX archive format
  5. Date: 27 Jul 1992 22:15:09 -0700
  6. Organization: Xenix Support, FICC
  7. Lines: 102
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <152l4tINNist@ftp.UU.NET>
  11. References: <14q4alINNate@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: peter@ferranti.com (Peter da Silva)
  16.  
  17. I'm not familiar with the ISO1001 format, but I would like to suggest a textual
  18. self-documenting format, like RFC822. You don't need to put the actual field
  19. names in every file header if you establish a property file at the beginning of
  20. the archive. For example:
  21.  
  22.     FieldCodeset: ASCII
  23.     FieldSeparator: <0A>
  24.  
  25. [ these two would be required for the initial header, and need to be in an
  26.   agreed on language. ]
  27.  
  28.     HeaderLength: 96
  29.     BodyLength: 0
  30.     Common: HeaderLength,BodyLength,FileName,ModificationTime,Owner
  31.  
  32. [ This establishes the common fields until the next Common field ]
  33.  
  34.     2746
  35.     13995
  36.     usr/local/src/pax/Makefile
  37.     19920723.194516.0001
  38.     peter
  39.  
  40. [ These are the header length, body length, filename, etcetera for the first
  41.   file ]
  42.  
  43.     FileComment: Remember to edit this for local architecture[...]
  44.  
  45. [ This is a part of the file system on the originating system. Would probably
  46.   end up in usr/local/src/pax/.Unresolved/Makefile on UNIX ]
  47.  
  48.     #!/bin/make
  49.     [...]
  50.  
  51. This should require a minimal amount of additional space, and would be
  52. indefinitely extensible. Older versions of the archive program could
  53. discard unknown headers, or stick them in a file somewhere for later
  54. messing around with. It should also be relatively easy to treat as a fixed
  55. record length format.
  56.  
  57. >     - Support for >32 bit systems
  58.  
  59. Inherent.
  60.  
  61. >     - Be extensible, to allow for future support of security information,
  62. >       contiguous files, system management information, special files,
  63. >       larger field sizes for dates, times, file lengths, etc.
  64.  
  65. Inherent.
  66.  
  67. >     - Support portability of file, user, group names and other
  68. >       file information across machines of differing codesets and/or
  69. >       locales (i.e. it should work on ASCII, EBCDIC, ISO 10646 and
  70. >       Shift-JIS systems alike).
  71.  
  72. With the caveat that a standard character set be used for the first two fields.
  73.  
  74. >     - The archive must be able to be stored on as many media types
  75. >       as possible, including but not limited to 9-track and streaming 
  76. >       tape, diskette, CDROM, ftp files, etc.
  77.  
  78. Inherent.
  79.  
  80. >         - Encryption of individual files in the archive
  81.  
  82. Simple extension: new file header.
  83.  
  84. >         - Compression of individual files in the archive
  85.  
  86. Ditto.
  87.  
  88. >         - Translation of file contents between differing
  89. >           codesets (i.e. format only needs to handle translation
  90. >           of file *names*, etc)
  91.  
  92. Ditto. ( add Body-Type )
  93.  
  94. >         - Storage of filesystem specific information (such as inodes)
  95.  
  96. Ditto.
  97.  
  98. >         - Direct mailability of the archive file (without translation,
  99. >           such as through uuencode)
  100.  
  101. Probably ditto, assuming no magic in the bodies or lines that are too long
  102. for mail.
  103.  
  104. This is obviously not a complete proposal. I would appreciate feedback and
  105. suggestions, and if they seem positive I'll go ahead and write a real proposal
  106. up. The intellectual property status and usage of RFC822 is presumably not
  107. going to be a problem.
  108.  
  109. -- 
  110. Peter da Silva                                               `-_-'
  111. $ EDIT/TECO LOVE                                              'U` 
  112. %TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
  113. Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
  114.  
  115.  
  116. Volume-Number: Volume 28, Number 64
  117.