Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/mod.std.unix.v7/text0005.txt

Internet Message Format | 1987-06-30 | 3.8 KB

From: hoptoad![e-mail] (John Gilmore)
To: [e-mail]
Cc: sun!amdahl![e-mail]
Date: Mon, 29 Sep 86 03:48:59 PDT

In the version of P1003 that I have (long before the Trial Use Standard,
since IEEE would rather make money than give it widespread distribution
in the Unix community) there is a problem with the tar format described.

[ I'd be interested to know how much they're making, but at less than $20
per 200 page hardback, I doubt it's much.  Also, remember that they've got
not only the costs of publication and distribution of the book itself to
pay for but also those of the reams of drafts, proposals, RFCs, and random
verbiage that get mailed around to everybody on the interest list.  -mod ]

Basically it is the same as V7 tar with some new types added for directories,
devices, named pipes, etc.  It also has some of the unused space in
the header blocks filled with owner name, group name, etc.  All good ideas.

Anyway, the problem is that directories are defined as a new file type
(linktype).  This works OK when talking to another P1003 "tar" program,
but I implemented it and tried it.  If you feed such a tape to a V7 or
4BSD tar program, it doesn't recognize the linktype, so it creates the
directory as a normal [empty] file.  This causes all the files that
should have gone into that directory to fail because the directory name
is now in use as a file name.  (I'm sure Sys V tar has the same problem.)

The temporary workaround I am using is to write the tapes with a linktype
of "directory" and a trailing slash in the file name.  This causes 4.2
to create it as a directory and causes V7 to fail at trying to create it
as a file.

I suggest that we change the "tar" format in the standard.  To what I
am not sure.  Maybe the above kludge is good enough.  Maybe we should go
back to the 4.2BSD style tar tape.

I also suggest that we actually implement and run a few of the other
"innovations" of this standard, before we standardize it...

[ Good idea.  Such things as Doug Gwyn's mkdir/rmdir implementation
are quite useful, especially when distributed for general use.  -mod ]

    John

PS:  I was on the APL Standards committee and there is always a strong
temptation to "fix" things rather than embed mistakes in concrete.
Resist!  The mistakes are already embedded, in user programs and file systems
and minds...

[ The committee is aware of that problem.  -mod ]

PPS:  Post the **&^&^$%#@ standard to the net!  This message needs to be
repeated until the bozo(s) who are preventing it get the message.  I'm sure
they are having lots of fun passing drafts back and forth via email while
we sit out here empty handed.

[ Not true.  The committee in general doesn't have machine-readable text
of the document, either (only the few people actually preparing the new
draft do):  it's IEEE, not the committee, that has imposed the current
moratorium on distributing text that "represents" (as they insist we
put it) the current document.  As I understand it, the restriction
applies only to actual Standards (whether Trial Use or Full Use).
I.e., it is likely that the draft between them will be available
by the previous mechanisms (anonymous FTP on the Internet and UUCP
from designated machines).

The Appendix I just posted was taken from the on-line copy of Draft 6
and I typed in changes found in the published book of the Trial Use Standard
(once known as Draft 7):  I don't have an on-line copy of the latter, either.

As the person responsible for distributing machine-readable text
representing previous drafts, I can assure you that *nobody* *ever*
passed them around by electronic mail:  think of the size of the thing!

Finally, it's not as if the document weren't publicly available.
Less heat and more light please:  this is a technical newsgroup,
not a shouting match.
-mod ]

Volume-Number: Volume 7, Number 6