[ On Wednesday, October 16, 2002 at 11:52:14 (-0400), Christos Zoulas wrote: ]
> Subject: Re: don't generate non-portable archives by default!!!! CVS commit: basesrc/bin/pax
>
> On Oct 16, 11:46am, woods@weird.com (Greg A. Woods) wrote:
> -- Subject: Re: don't generate non-portable archives by default!!!! CVS commi
> 
> The choice that I had was to enable or disable gnu extensions by
> default.  NetBSD had the extensions turned on by default [by virtue
> of using gnu-tar as tar], so I followed the existing practice.

I realize that.  Howerver it is that very existing practice which has
gotten "us" into this situation in the first place.

Indeed it seems that even the GNU Tar maintainers regret having gotten
themseleves (and everyone else along with them) into this situation of
having created a widely used but non-standard and non-portable and now
non-compatible extension to the Standard Portable Archive Interchange
Format and the ongoing extensions to that standard PAX.

To paraphrase someone's posting that I ran across in doing research on
this issue:  It is better to fail when creating the archive if a file
cannot be represented in the archive than it is to fail when attempting
to restore the non-portable archive.

The "tar" front-end to "pax" really should produce only portable
standards compliant archives by default, just as its native command-line
interface does.

> Please note that the gnu extensions are not disallowed by the
> standard.

Well, it doesn't seem quite that simple, at least not if you go by what
the GNU Tar maintainers themselves claim.....

> The long filename and long link entries, are extra entries
> of ././@LongLink that will get extracted as mode 0 empty files by
> tar programs that are not aware of the extensions.

Yes, perhaps by some, but not by all it would seem.  I don't have test
examples handy but I refer to the words of both the GNU Tar maintainers
in the "GNU `tar' and POSIX `tar'" section of their manual, as well as
to hints alluded to by the Star author and his supporters.

>  There was no
> way to generate 100% USDA approved ustar files before. Now you can
> by using "tar --strict", so in my eyes this is an improvement.

Actually there always was:  pax itself.

If users really do need the ability to store files which cannot
currently be portably represented in strict IEEE Std 1003.1-1990
compliant archives then the way to help them is to implement the new
POSIX 1003.2b (-2001?) extensions.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>