home *** CD-ROM | disk | FTP | other *** search
- From: seismo!munnari!yabbie.oz!rcodi (Ian Donaldson)
-
- In article <8208@ut-sally.UUCP>:
- > From: MIKEMAC%UNBMVS1.BITNET@wiscvm.wisc.edu (Michael MacDonald)
- >
- > I have just finished working on a CPIO tape reader and approx 1 year
- > ago a TAR tape reader for our IBM3090 180/vf running MVS/XA.
-
- Sounds reasonable. About the same time it would seem, I wrote an implementation
- of Tar in Pascal under NOS on a Cyber 170, with 60-bit words. See comments
- below.
-
- > #define PFXSIZ 155
- > char prefix[PFXSIZ];
- >
- > which is used when name isn't big enough. The total of the two is set
- > to match the minimum permissible value of PATH_MAX. -mod ]
-
- I don't agree - there should be no limit to the pathname size.
- 4.2bsd has a limit of MAXPATHLEN (unfortunately), but it is a reasonable
- value (1024). Probably the reason that was enforced was a side-effect
- of the speedups to nami(), using one copyinstr() rather than judicious use
- of fubyte(). The code could be tweaked to overcome this limit without
- too much trouble no doubt. V7 and SVR2 don't have any such limit.
-
- 100+155 just doesn't seem enough in comparison for Tar, but in practice
- it would suffice 99% of the time.
-
- > 4) All of the tape drives that I have worked with (not that many)
- > are capable of writing a short block. If TAR would recognize
- > a physical end of file rather than two blocks of hex 00's.
- > This would solve a number of problems with TAR.
-
- Yes, but tar is not always used with tapes, and is not always used
- with machines that have 8-bit bytes (eg: Cyber).
-
- I have often written tar archives to raw disk partitions. If you were
- to use the OS EOF concept here, it would fail miserably since the archive
- is only a fraction of the size of the partition usually.
-
- The implementation of Tar I had on the Cyber worked well but it it would have
- been much more complicated to make it recognize a physical EOF half way through
- a 60-bit word (yes there are 7.5 8-bit bytes/60 bit word, and thats
- how they arrive from the tape-drives or disks). NOS does provide a
- rather perverted way of determing how many unused bits are in the last
- word, but that information is typically only available to the assembly
- language programmer, or system guru, and is device dependent.
-
- Remember that tar and cpio work with any "file" that you tell them to.
- They are not hard-coded for tapes.
-
- > 5) Limited amount of Unix dependent information in the header.
- > If a *backup* system is used for data interchange is it really
- > necessary to add many Operating System dependent features.
-
- Yes, but remember this is a UNIX archive mechanism. Thus it should be able
- to save/restore files on most UNIX systems. It was not designed for
- other operating systems. Information that is not common to most
- implementations of UNIX is probably not worth putting in the header.
- Those implementations that don't support such information can safely
- ignore it anyway.
- There is no such information there at the moment in Tar headers.
- There is an inode/dev pair in cpio's header however, but this is used
- for link determination at extract time.
-
- [ We are discussing standardizing a data interchange/archive format
- in a standard that its authors explicitly wanted to be implementable
- on hosted, i.e., non-UNIX-based, systems. The inclusion of inode
- numbers is a problem for such implementations, especially when it
- is not necessary, as demonstrated by the tar format. -mod ]
-
- > CPIO Format comments.
- > 1) Data is not block oriented. This slows down processing
- > considerably.
-
- Its a time/space tradeoff.
-
- Ian D.
-
-
- Volume-Number: Volume 11, Number 54
-
-