Re: libpax?

>From: =?iso-8859-1?Q?Wolfgang_J=E4hrling?= <[email protected]>

>I don't know if anyone has ever contacted you before in this regard
>(from the mainling list archive, it seems nobody did).

>I got a very exciting idea.  You would benefit greatly from the
>extremely large userbase of the Hurd by doing a pax library, so that we
>can easiely write a tar file system for the Hurd. :P

Mmmm not shure if this is the right smiley ;-)

In 1978 people most likely have been right when they stated that UNIX
was the most popular OS on the world because there have been more than
100 UNIX installations... today numbers are different.

>But, em, seriously: We will implement a tar file system for the GNU
>operating system (sometimes called GNU/Hurd) sooner or later anyway, as
>this is a much requested feature (I know two people who said they're
>interested in developing it, while of course I'm not sure if they'll
>actually do it eventually) and sharing the code between the normal
>program and the file system by putting it in a library seems like a good
>idea.  Thus I want to ask if there is any chance that the archive
>handling stuff will be put in a library.  Another variant is to make
>tarfs an optional part of paxutils that will only build on GNU (which
>might be a good idea anyway), thus one would be able to share the code
>easiely anyway, and a library would not be strictly needed.  I'd like to
>hear which variant you prefer.

If you look at freshmeat it is easy to find libtar.... however it suffers
from the same bugs as PAX, GNU tar & GNU cpio. It definitely is a better 
start because it is writen cleanly.

Please keep in mind that it is a bad idea to have a filesystem that is
based on buggy code.

>I feel that the resulting possibillity to implement the feature
>described above would give GNU yet another advantage over non-free
>systems.  And GNU is supposed to be superior, not only on the moral
>level, but also on the technical level, is it? :)

GNU is not the worst, but it definitely is not the best.

To verify, have a look at ftp://ftp.fokus.gmd.de/pub/unix/star/testscripts/
and read the file README.quicktest it contains a quick POSIX compliance test
for the most frequent bugs found in tar implementations. It is only POSIX.1-1990
but this currently does not matter as long as star is the only POSIX.1-2001
compliant imlpementation. The program 'tartest' which is part of the star
distribution has been hacked quickly (~ one day), checking for POSIX.1-2001
would take more time.

OK; back to the quicktest....

star-1.5a04 and star-1.4.1 are the only TAR implementations that pass the test.

Solaris tar is the only TAR implementation that 'nearly' passes: it puts more than
12 bits into the mode/permission field (which is a minor problem as all known
tar implementations ignore the bits above the 12th) and it is not able to extract
Contiguous files.

PAX from Keith Muller (UCB) as well as GNU tar & GNU cpio fail badly with real world
problems. PAX is the worst: it is not even correct for non-large files (< 2 GB).

Be sure to test the tar implementation in list & in extract mode. This makes sense
as Solaris tar is able to list Contiguous files but not able to extract them and
because GNU tar has a different set of bugs in list vs. extract mode.
To be honest, GNUtar 1.13.25 extracts the test archive correctly but fails when
you try to create a TAR archive. Other programs usually, amongst other problems,
don't hande archives correctly when the files use up the whole space for the 
filename and don't use null terminated filenames.


Jörg

 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]		(uni)  If you don't have iso-8859-1
       [email protected]		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix