std-unix@ut-sally.UUCP (Moderator, John Quarterman) (09/29/86)
From: hoptoad!gnu@lll-crg.arpa (John Gilmore) To: std-unix@sally.utexas.edu Cc: sun!amdahl!chongo@lll-crg.arpa 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