"Peter T. Breuer" wrote:
>
> In comp.os.linux.misc tbutler@rational.com wrote:
> > Peter T Breuer writes:
> >> I have! People who offer recommendations on usenet, as in any walk of
> >> life whatsoever, are expected to declare an interest if they have one.
> >> That's simple honesty.
>
> > Financial interest, or any interest at all?
>
> An interest which normally would be expected to bias their opinion one
> way or the other. Such as being the author of the utility recommended.

How about compound interest?

-am © 2003

"Ed Murphy" <emurphy42@socal.rr.com> wrote on Fri, 08 Aug 2003 02:24:16 GMT

Well, it is bad to see that Linux followers nearly always reduce the list of
crosspostings to a single Linux only group. Is this to avoid discussions with
people with a broader background?

Well, I definitely do not read "comp.os.linux.misc" and I only found your
article by chance when using google to look for something else.

***********
If you like a discussion, don't shorten the list of newsgroups!
***********

>Jumping Jesus on a pogo stick, will you *both* just bite back your egos
>for thirty seconds and Google on (posix tar)? No, don't even bother,
>I'll do it for you. At the end of this message, I have quoted the first
>thing it turns up.

Doing this, I get a lot of wrong information that is prejudiced by the
incorrect text from http://www.gnu.org/manual/tar/html_node/tar_117.html

Let me comment in this detail later on....

>Joerg's ftp://ftp.berlios.de/pub/star/STARvsGNUTAR document appears
>to discuss *what* can be done, and stops there. The GNU authors
>discuss *why* things should be done, at great length. Joerg, I think
>you and your project would greatly benefit by learning from this aspect
>(even if, as claimed, star is superior to GNU tar in other areas).

Sorry, I don't understand you. GNU authors do not discuss *why* things should
be done.

>Joerg, here are some direct questions for you:

>* Are you the author of star? (Please answer either "yes" or "no",
> so as to make one of Peter's quibbles go away. For the record,
> this is frequently one of my quibbles as well; I *hate* it when
> a yes-or-no question receives an answer that does not start with
> one of "yes", "no", "probably", "probably not", "I don't know",
> or "it depends on <one or more conditions>".)

Sorry, I hate it to answer to arrogant, uninformed and lazy trolls like
Mr. Breuer. Answering your question explitictly here in a forum would show him
that he succeeds with his attitude to daunt people. He is just unable
do do scientific work. All his questions are answered in texts that are
part of the star source distribution. If he refuses to read the few files
I pointed him to, I cannot help. His problem is that he does not want a discussion
and only trolls: You point him to a text that answers his question in a more
explicit way that it could be done in a news group and he replies with unrelated
new questions.

Believe me, even if I would explicitly answer this questions, he would
immediately start a new troll attack.

/*--------------------------------------------------------------------------*/

Now to your questions:

>* What versions exist of the POSIX standards for tar? (Your
> STARvsGNUTAR document mentions 1003.1-1988 and 1003.1-2001. GNU's
> document mentions 1003.1-1990. Are there any others?)

1003.1-1988 1003.1-1990 1003.1-1995 SUSv1 (UNIX-95) SUSv2 (UNIX-98)
SUSv3 (1003.1-2001)

>* How significant are the differences between these versions? In
> particular (since this was the case being pointed to), what is
> the earliest version that allows filenames > 100 characters?

1003.1-1988, I have a draft from august 1987 that is close to identical
with the final 1003.1-1988 and definitely has not a single difference regarding
filename length between 101 an 255 chars.


>* To what extent does GNU tar support each of these standards,
> assuming proper configuration (e.g. the POSIXLY_CORRECT
> environment variable being set)?

POSIXLY_CORRECT is meaningless. It is just a GNU playball to confuse people and
only affects parts of the command line option parsing. It neither affects the
TAR archive format used by GNU tar nor the command line options that contradict
UNIX-98.

GNU tar is based on a program called PD tar / SUG tar (Sun User Group tar)
from John Gilmore.

This program has been first published on the Usenix spring conference in
February 1987 in SF. A second more widely noticed publishing did occur at the
Sun User Group conference in december 1987 in San Jose.

If you like to check what this version of tar did, get the source from:

ftp://ftp.berlios.de/pub/star/sugtar.tar.gz

Sugtar did implement a true subset of the POSIX.1-1988 standard.
The following differences to POSIX.1-1988 are present:

- The octal numbers are left blank filled instead of left zero ('0')
filled - a late change in the standard.

- The magic number/version in the tar header reads: "ustar \0" instead
of "ustar\000".
This has already been in the August 1987 draft - I have no older draft.

- It does not support filenames > 100 chars.
This has already been in the August 1987 draft - I have no older draft.

If you like to check the exact differentces, you need to use the program
"tartest" that comes with every star source.

The non-compliances have been added later by FSF when they adopted Sugtar to
GNU tar.

>* To what extent does star support each of these standards?

Star fully implements the POSIX.1-1988 ... SUSv2 (UNIX-98) standard.
Star in addition supports POSIX.1-2001 since 2 years.

Star implements a lot of extensions to the POSIX.1-2001 tar archive format
extensions using the method for local extensions described in POSIX.1-2001.
The main purpose for these extensions are to implement ufsdump alike
features for true incremental dumps.

As star has been written more or less cleanly, it is simple to add new
extensiond by using the POSIX.1-2001 extensions (see below for more
information).

>* What difficulties may arise when unpacking a star archive using
> other tar software? What star options should appropriately be
> used to avoid these difficulties? How does this stack up to
> GNU tar (as discussed at length in the document quoted below)?

If you try to unpack a star archive using a real non-buggy tar implementation,
absolutely no problems occur. If you use the POSIX.1-2001 extensions, you may
have to live with a lot of warnings because up to now, star is the only program
that implements POSIX.1-2001 tar archives.

..... nearly all tar implementations are correct enough to extract star's
archives.

Exceptions:

- old versions of PAX (they implement a broken checksum algorithm)

- GNU tar.

A complete descripion of the problems with GNU tar is in README.otherbugs

On the other side: A lot of problems arise when you try to unpack GNU tar
archives (which are not tar archives although they look similar) by other
tar implementations that do not know about the specifics of the GNU tar
noncompliances.

To give you an example, I recommend to have a look at the MySQL web page:

http://www.mysql.com/downloads/mysql-3.23.html

They incorrectly state that Sun's tar is buggy and you have to unpack
the archives with GNU tar for this reson.

The truth is that the archives that they did create with GNU tar are extremely
buggy and even star has problems to unpack them.

It seems that they did create the archives using GNU tar -O which should
(from reading the man page) create archives that are 100% compliant to old
(1982 BSD) tar archive formats. If you have a closer look, you find the
following:

- Most TAR file headers in the mysql archive look like 1982 BSD tar
archive headers.

- Some headers which are related to filenames > 100 chars look
like GNU tar headers.

This shows you how rotten the overall state of GNU tar is!
GNU tar does not implement a clean abstract view based on different
archive format versions but silently assumes everything is GNU tar and in this
case just emmits archive headers that are incorrect instead of returning
an error: "This file may not be achived in a way that is compliant to
selected archive format (in this case the old 1982 BSD tar archive format) - skipping".

If you like to unpack mysql-3.23.57.tar.gz (which can be found on the URL
mentined above) using star, you need to call

star H=gtar -tv < mysql-3.23.57.tar.gz

and will se a lot of warnings because star knows that you force it to unpack
an archive that itself states to be NON-GNU using GNU tar extensions.

If you don't use star H=gtar, you will see warnings like:

star: WARNING: Archive contains unknown typeflag 'L' (0x4C).

and star does what would be expected for an unknown tar archive that looks
like an old tar archive: it handles the headers as if they were related to plain
files.


>* Do you know of any ways in which GNU tar is superior to star
> (other than being more widely used, and more familiar to a wide
> audience)?

This depends on how you look at GNU tar. Many of the so called "GNU tar
extended features" have massive bugs if you have a non-trivial situation.
As an example: The auto-tape-archive split functionality used for multi
volume archives does not work if the archive would have to be split in the
middle of the processing of a sparse file.

There are moany other similar bugs in GNU tar....

>Okay, here's the quote, as promised.

>http://www.gnu.org/manual/tar/html_node/tar_117.html

This file has been written at FSF in 1994 - most likely by François Pinard
who was the GNU tar maintainer between ~ 1992 and ~ 1997. In 1995, I send
him a description about what in this text is wrong and why it is wrong.
AFAIR, he replied that he had to discuss this with RMS and this was the
last reaction on this topic. Later, when Paul Eggert has become the GNU tar
maintainer, I send a repeated note on the false claims in the text above but
did not get any reaction.

>GNU tar was based on an early draft of the POSIX 1003.1 ustar standard.

This _may_ be true, but the author of the text above is definitely unable to
prove it! So even from the subjective point of view of the author of the text
above, the claim is untrue.

I have no older draft document than one from august 1987. GNU tar definitely
violates this document and even PD-tar from John Gilmore (the GNU tar parent)
does not implement completely what has been in the august 1987 draft.

Fact is: PD-tar did not implement file names > 100 & < 256 Bytes but did leave
the space in the TAR header that has been reserved by POSIX for this
purpose untouched.

Fact is for this reason: When FSF people started to work on PD-tar/Sugtar
to make GNU tar from it, POSIX.1-1988 already has been finally approved.


>GNU extensions to tar, such as the support for file names longer than 100
>characters, use portions of the tar header record which were specified in
>that POSIX draft as unused. Subsequent changes in POSIX have allocated the
>same parts of the header record for other purposes. As a result, GNU tar
>is incompatible with the current POSIX spec, and with tar programs that
>follow it.

Completely wrong (see notes above):

FSF did allocate the space reserved for long path names _after_ the final
POSIX.1-1988 came out.


>We plan to reimplement these GNU extensions in a new way which is upward
>compatible with the latest POSIX tar format, but we don't know when this
>will be done.

This text is 9 years old! You may judge yorself and guess if there first will
be GNU Hurd or a POSIX.1-1988 compliant GNU tar ;-)


>In the mean time, there is simply no telling what might happen if you read
>a GNU tar archive, which uses the GNU extensions, using some other tar
>program. So if you want to read the archive with another tar program, be
>sure to write it using the `--old-archive' option (`-o').

As I did show up with the MySQL archive, you see that this is a lie.


>@FIXME{is there a way to tell which flavor of tar was used to write a
>particular archive before you try to read it?}

YES: there is a way, star started to implement this kind of software in 1994.


>Traditionally, old tars have a limit of 100 characters. GNU tar attempted
>two different approaches to overcome this limit, using and extending a
>format specified by a draft of some P1003.1. The first way was not that
>successful, and involved `@MaNgLeD@' file names, or such; while a second
>approach used `././@LongLink' and other tricks, yielding better success.
>In theory, GNU tar should be able to handle file names of practically
>unlimited length. So, if GNU tar fails to dump and retrieve files having
>more than 100 characters, then there is a bug in GNU tar, indeed.

The method of using `@MaNgLeD@' file names was a really bad idea.

When I started thinking on tar extensions in 1985 (note that I already did
implement all features that POSIX.1-1988 introduced for TAR except for longer
filenames) I already has a plan that was similar to the `././@LongLink' method
used by GNU tar starting around 1992. I only did not implement it because there
was no ducumented way in the tar archive format to cleanly introduce this kind
of extensions.

>But, being strictly POSIX, the limit was still 100 characters. For various
>other purposes, GNU tar used areas left unassigned in the POSIX draft.
>POSIX later revised P1003.1 ustar format by assigning previously unused
>header fields, in such a way that the upper limit for file name length was
>raised to 256 characters. However, the actual POSIX limit oscillates
>between 100 and 256, depending on the precise location of slashes in full
>file name (this is rather ugly). Since GNU tar use the same fields for
>quite other purposes, it became incompatible with the latest POSIX
>standards.

This is a clear lie! As I already mentioned, I know of no POSIX draft that did
_not_ mention the method to implement filenames up to 255 characters.
_Before_ FSF started to hack the code, the so called "later revised P1003.1 ustar
format" has already become a final standard (in 1988).

>For longer or non-fitting file names, we plan to use yet another set of
>GNU extensions, but this time, complying with the provisions POSIX offers
>for extending the format, rather than conflicting with it. Whenever an
>archive uses old GNU tar extension format or POSIX extensions, would it
>be for very long file names or other specialities, this archive becomes
>non-portable to other tar implementations. In fact, anything can happen.
>The most forgiving tars will merely unpack the file using a wrong name,
>and maybe create another file named something like `@LongName', with the
>true file name in it. tars not protecting themselves may segment violate!

Or in short form: GNU tar archives are all non-portable if they
include filenames > 100 chars.

Star _really_ had this kind of a problem that has been incorrectly claimed for
GNU tar. Star did introduce a lot of extensions in 1985!

But I managed to start with a POSIX.1-1988 compliant method in 1993 and did
this by adding auto-format detection. So old star archives from the time
between 1985 ... 1994 could be unpacked without problems and new archives
become POSIX compliant. If the FSF people would have done real work instead of
writing papers that claim false things, the GNU tar compatibility problem would
not have been present now. Remember that in 1995 is was very very unlikely that
you would find a long (> 100 char) filename in an archive used for data
exchange.

>Compatibility concerns make all this thing more difficult, as we will
>have to support all these things together, for a while. GNU tar should be
>able to produce and read true POSIX format files, while being able to
>detect old GNU tar formats, besides old V7 format, and process them
>conveniently. It would take years before this whole area stabilizes...

If the FSF people would have worked on GNU tar in 1994 instead of burbling
about the problems, GNU tar _now_ would already be OK and nobody would have
noticed the problem.

*****
Let me make a break here.

It does not make sense to comment every single paragraph of the FSF tar
document as it is only burbling and not related to real work. 9 years have been
passed since it has been written, nothing has changed and I suspect that nothing
will happen in the next 9 years.

*****

....... many untrue things smipped

>POSIX format cannot represent very long names, volume headers, splitting
>of files in multi-volumes, sparse files, and incremental dumps; these
>would be all disallowed if --posix or POSIXLY_CORRECT. Otherwise, if tar
>is given long names, or `-[VMSgG]', then it should automatically go
>non-POSIX. I think this is easily granted without much discussion.

Wrong (at least since december 2001):

POSIX.1-2001 defines a TAR format with absolutely no limitations.
Star implemented this format 5 months before the POSIX.1-2001
standard has been approved (but after I had some negotioations
with the standard committee to make sure that nothing will be changed
before the final POSIX.1-2001 comes out).


>Another point is that only mtime is stored in POSIX archives, while GNU
>tar currently also store atime and ctime. If we want GNU tar to go closer
>to POSIX, my choice would be to drop atime and ctime support on average.
>On the other hand, I perceive that full dumps or incremental dumps need
>atime and ctime support, so for those special applications, POSIX has to
>be avoided altogether.

Wrong:

- GNU tar usually does not store these times!
Star does for all archive types (except for 100% compliant
POSIX.1-1988 ustar) since 1985.....

- POSIX.1-2001 allows to archive all dates and it also allows to achive
the time stams at arbitrary precision.
Star uses nanosecond precision because this is what Solaris supports
in the file's time stamps.

To give you a hint on how extensible the POSIX.1-2001 format is, here is the
content of a extended 2001 tar header:

/*--------------------------------------------------------------------------*/
30 atime=1060944999.265118000
30 ctime=1060675850.923518000
30 mtime=1060675150.996080000
23 SCHILY.dev=35651591
21 SCHILY.ino=186033
18 SCHILY.nlink=1
27 SCHILY.filetype=regular
/*--------------------------------------------------------------------------*/

Other fields defined by POSIX:

uid/uname in case the number does not fit or the name uses
UNICODE (e.g. japanese) characters.

gid/gname See above


path long path (no limitation) or needs UNICODE characters

linkpath See above

size size is > 8 GB.

charset Charset used inside the files
comment text ignored by the inmplementation

All numbers are decimal numbers with no length limitation.

Local extensions are explicitly allowed if they start with the (all caps)
name of the vendor. For this reason, my extensions use SCHILY. as prefix.

My other extensions not shown in the example above:

SCHILY.devmajor Major if > 2097151
SCHILY.devminor minor if > 2097151

SCHILY.acl.access Current ACL in portable text form
SCHILY.acl.default Inheritable ACL in portable text form

SCHILY.fflags Extended file flags (from *BSD and Linux) in portable
text form

SCHILY.dev st_dev (needed for true incremental dumps)
SCHILY.ino st_ino (needed for true incremental dumps)

SCHILY.nlink link count (needed for star -diff)

SCHILY.filetype file type in text form allows to archive _all_ file
types

SCHILY.realsize Real file size for sparce files

SCHILY.dir Directory content (used for true incremental dumps and
for star -diff)

Please note that unlike the burbling from the GNU tar maintainer in 1994,
I did write descriptions for the fields I use and include them with every
star release. Unfortunately only a few people seem to read them.

.....

rest snipped...


I hope this helps to understand why star is better than GNU tar and why I would
never volountarily use GNU tar if I have star available. To be explicit:
On of the first things I do is to use GNU tar to unpack the star source archive
if I start working on a new machine that does not yet have /opt/schily/

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

On Fri, 15 Aug 2003 13:08:36 +0000, Joerg Schilling wrote:

> "Ed Murphy" <emurphy42@socal.rr.com> wrote on Fri, 08 Aug 2003 02:24:16 GMT

> Well, it is bad to see that Linux followers nearly always reduce the list of
> crosspostings to a single Linux only group. Is this to avoid discussions with
> people with a broader background?

Peter reduced the crossposting, not me. I don't know why he did it.

>>Joerg's ftp://ftp.berlios.de/pub/star/STARvsGNUTAR document appears
>>to discuss *what* can be done, and stops there. The GNU authors
>>discuss *why* things should be done, at great length. Joerg, I think
>>you and your project would greatly benefit by learning from this aspect
>>(even if, as claimed, star is superior to GNU tar in other areas).

> Sorry, I don't understand you. GNU authors do not discuss *why* things should
> be done.

But they do! The file I quoted is chock full of "we (do / did /
probably should do) X because Y". All right, you believe their
conclusions are wrong, but that's a different issue.

>>Joerg, here are some direct questions for you:

>>* Are you the author of star? (Please answer either "yes" or "no",
>> so as to make one of Peter's quibbles go away. For the record,
>> this is frequently one of my quibbles as well; I *hate* it when
>> a yes-or-no question receives an answer that does not start with
>> one of "yes", "no", "probably", "probably not", "I don't know",
>> or "it depends on <one or more conditions>".)

> Sorry, I hate it to answer to arrogant, uninformed and lazy trolls like
> Mr. Breuer. Answering your question explitictly here in a forum would show him
> that he succeeds with his attitude to daunt people.

Never mind Peter. Answer *my* question. Are you the author of
star? (And, implicitly: will you continue to refuse to answer
a simple direct question, whose true answer is fairly obvious,
for the sole purpose of spiting Peter?)

[Snipped large volume of specific comments on star vs GNU tar. You
made them, and they seem plausible, but my knowledge/interest in tar
is quite insufficient to determine their accuracy. I will leave it
to others to comment on this.]

On Thu, 07 Aug 2003 18:23:28 GMT, Barry Margolin <barry.margolin@level3.com>:
> In article <qmttgb.1b.ln@news.it.uc3m.es>,
> Peter T. Breuer <ptb@oboe.it.uc3m.es> wrote:
> >In comp.os.linux.misc Joerg Schilling <js@cs.tu-berlin.de> wrote:
> [Lots of flames snipped]
>
> Is it really necessary for every thread in a Unix newsgroup that mentions
> tar to degenerate into a flamewar about gtar vs. star?

I believe the most significant variable here is Peter T. Breuer, not
tar or star. I'm not suggesting this is either good or bad. I've
learned a lot from Peter in the posts I've seen from him, and I've often
been infuriated by his manner. Either killfile him or listen to him.
That's all I've managed to come up with.

Peter does say tar works for him "mostly." That's a pretty big
"mostly." Still, not big enough to read up on possible alternatives
apparently.


--
Any technology distinguishable from magic is insufficiently advanced.
(*) http://www.spots.ab.ca/~keeling
- - http://learn.to/quote (Deutsch) http://quote.6x.to (Eng.)
Spammers! http://www.spots.ab.ca/~keeling/spammers.html

In comp.os.linux.misc s. keeling <keeling@spots.ab.ca> wrote:
> On Thu, 07 Aug 2003 18:23:28 GMT, Barry Margolin <barry.margolin@level3.com>:
>> In article <qmttgb.1b.ln@news.it.uc3m.es>,
>> Peter T. Breuer <ptb@oboe.it.uc3m.es> wrote:
>> >In comp.os.linux.misc Joerg Schilling <js@cs.tu-berlin.de> wrote:
>> [Lots of flames snipped]
>>
>> Is it really necessary for every thread in a Unix newsgroup that mentions
>> tar to degenerate into a flamewar about gtar vs. star?

> I believe the most significant variable here is Peter T. Breuer, not
> tar or star. I'm not suggesting this is either good or bad. I've

I have no opinion on star :-). I simply have a bad experience of the
behaviour of its author, who attempted to recommend and promote it on
comp.os.linux.misc without announcing himself as being connected in any
way to it. In this thread.

I downloaded star, discovered he was the author, and called him on it.

To this point, I don't believe that there has been a simple yes/no
admission by the author that he is the author, and I don't know why.

> learned a lot from Peter in the posts I've seen from him, and I've often
> been infuriated by his manner. Either killfile him or listen to him.
> That's all I've managed to come up with.

> Peter does say tar works for him "mostly." That's a pretty big
> "mostly." Still, not big enough to read up on possible alternatives

It's a pretty small "mostly". Tar has been doing the daily backups for
hundreds, nay, thousands, of people for me every day for the past ten
years. There have been no complaints about it, but then that means
nothing. *I* know what the difficulties are (buffer underruns while
streaming over the net, file name length limits, difficulties
untarring readonly files on nfs, etc.). They simply aren't a problem in
practice.

> apparently.

If I wanted to use something else, I'd use cpio. Meanwhile, debian and
slackware package everything using tar.

Peter

Peter T. Breuer wrote:
> To this point, I don't believe that there has been a simple yes/no
> admission by the author that he is the author, and I don't know why.

This thread is cross-posted to comp.unix.solaris. Joerg is a
regular contributor to comp.unix.solaris and has been for years.
It is very well known on comp.unix.solaris that he is author of star.

(You may also be interested to know that he is the author
of cdrecord. Chances are, if you've ever burned a CD on
Linux, you've used cdrecord.)

And yes, Joerg is quite vocal about the virtues of his software.
For the most part, I believe this springs from the same thing
that (I assume) causes him to write it: enthusiasm for and
enjoyment of good software.

- Logan

[Peter T. Breuer]:
>
[Peter T. Breuer]:
>
> I see no direct connection between the two. I write software too,
> and I do not go around saying "use THIS, it's great, much better
> than THAT", without saying that I am the author of THIS, at
> least. Simple conscience would impel me.

star is almost twenty years old! it's the backup method of choice in
Amanda. it's the only free tar implementation which complies with
standards and can interoperate with almost any other implementation.
why are you so hung up on who wrote it? why does it matter? the
virtues of the software should be enough to convince you.

> When a person manifests himself as unable to understand other
> people, then doubt is cast on his general powers of understanding,
> extending to understanding of how his code satisfies peoples
> needs, or not.

indeed. *plonk*

--
Kjetil T. | read and make up your own mind
| http://www.cactus48.com/truth.html

In comp.os.linux.misc Joerg Schilling <js@cs.tu-berlin.de> wrote:
> In article <slrnbkghur.b9s.keeling@infidel.spots.ab.ca>,
> s. keeling <keeling@spots.ab.ca> wrote:

>>I believe the most significant variable here is Peter T. Breuer, not
>>tar or star. I'm not suggesting this is either good or bad. I've
> ...
>>Peter does say tar works for him "mostly." That's a pretty big
>>"mostly." Still, not big enough to read up on possible alternatives
>>apparently.

> Do you relly like to take someone for serious who uses the word 'tar' but
> does not seem to notice that he is rather talking about GNU tar?

I notice just fine. And no, I do not distinguish. Maybe because gnu
tar is the tar on gnu/linux, and guess where I am posting ... or maybe
because I don't care, or maybe because I like annoying people who behave
dishonestly. You guess.

> If you like to have a serous CS related discussion with a person, this
> person needs to have a minimal scientific backgound. The only result, I did
> see from the discussion was that Mr. Peter T. Breuer is completely missing a
> scientific background.

It's Prof. Dr. to you, joergie-baby, and your research needs a little
upping. No, I don't care.

Peter

In article <45u9ib.obi.ln@news.it.uc3m.es>,
Peter T. Breuer <ptb@oboe.it.uc3m.es> wrote:
>In comp.os.linux.misc Kjetil Torgrim Homme <kjetilho@yksi.ifi.uio.no> wrote:
>> [Peter T. Breuer]:
>>>
>> [Peter T. Breuer]:
>>>
>>> I see no direct connection between the two. I write software too,
>>> and I do not go around saying "use THIS, it's great, much better
>>> than THAT", without saying that I am the author of THIS, at
>>> least. Simple conscience would impel me.
>
>> star is almost twenty years old!
>
>So is tar.

tar is from 1978 (first known complete source), so tar is 25 years old now!

It started shortly after the UNIX version 7
distribution came out, so people who did run
UNIX.v7 on PDP-11 or MC86000 in 1982 did not
have it. People with BSD on VAX did have it.



star is from 1982 (extract only) and April 1985 (first complete create/extract).
So star is 21 or 18 years old (depending how you count).

It started because somebody from a BSD machine
did send a Modula-II source tape to TU-Berlin.



PD-tar is from August 1985 so it is 18 years old now.

It did die in 1989 when it has been taken over
by GNU tar.


GNU tar started in 1989 so it is only 14 years old.
It is based on PD-tar, but PD-tar did not violate the standard
as GNU tar does.

You confused littele boy are talking about
GNU tar. This is comp.unix.solaris, people
here think of tar (not GNU tar) when they
read 'tar'.

GNU tar archives cannot be archived by vanilla
tar implementations in many cases so GNU tar is
not tar. Either try to understand what tar is
or stay away. People here like to have a discussion
that at least has a minimal scientific background.


--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

In comp.os.linux.misc Joerg Schilling <js@cs.tu-berlin.de> wrote:
> In article <45u9ib.obi.ln@news.it.uc3m.es>, Peter T. Breuer <ptb@oboe.it.uc3m.es> wrote:
>>In comp.os.linux.misc Kjetil Torgrim Homme <kjetilho@yksi.ifi.uio.no> wrote:
>>> [Peter T. Breuer]:
>>>>
>>>> I see no direct connection between the two. I write software too,
>>>> and I do not go around saying "use THIS, it's great, much better
>>>> than THAT", without saying that I am the author of THIS, at
>>>> least. Simple conscience would impel me.

And your answer IS ...?

>>> star is almost twenty years old!


> GNU tar [...]
> It is based on PD-tar, but PD-tar did not violate the standard
> as GNU tar does.

And so? What standard, and what violation, BTW? And another BTW, what is
this ever-increasing indent in your post for?

> You confused littele boy are talking about
> GNU tar. This is comp.unix.solaris, people

No, it isn't, this is comp.os.linux.misc and I don't know why you bother
to post your garbage here. I've taken pains on occasion in the past to
stop the cross-posting in this thread, but if it will annoy you
sufficiently, I'm prepared to allow it to continue ...

> here think of tar (not GNU tar) when they
> read 'tar'.

I presume they think of solaris tar, which presumably still requires a
-f - to read from stdin (not that I know, have checked, or care, but
wild and unsubstantiated allegations seem to be where you are at..).
Is that germane to your habit of self-promotion without acknowledgement?

And what is the matter with your paragraphs? Are you not capable of
posting at 72 chars per line all of a sudden?

> GNU tar archives cannot be archived by vanilla
> tar implementations in many cases so GNU tar is

Uhhh .. fault in parse. Maybe one of those was "UNarchived", in your
head.

> not tar. Either try to understand what tar is

I think you mean tar is not a guitar, surely?

> or stay away. People here like to have a discussion
> that at least has a minimal scientific background.

Like what? I don't care two hoots about tar or gtar or star or btar or
whatever. The only discussion here is on whether you will own up to
being the author of star (which I would not touch with a bargepole,
seeing the mental difficulties its alleged author has) when you post
to unsuspecting people on usenet recommending it.

> EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jrg Schilling D-13353 Berlin
> js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
> schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
> URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Try adding to your sig, "author of star, a tar baby".

Peter