Re: Difference between tar and ar



On 2006-03-27, Steve Kirkendall <skirkendall@xxxxxxxxxxxx> wrote:
Tristan Miller wrote:

Greetings.

Quoth the GNU ar(1) man page:
The GNU ar program creates, modifies, and extracts from archives. An
archive is a single file holding a collection of other files in a
structure that makes it possible to retrieve the original individual
files (called members of the archive).

The original files' contents, mode (permissions), timestamp, owner,
and group are preserved in the archive, and can be restored on
extraction.

This description could apply equally well to tar. So why two separate
programs and file formats? Is there something about the ar format which
makes it particularly well-suited for making executable code libraries but
not general-purpose archives? And likewise, is there something about the
tar format which makes it unsuitable for executable code libraries?

ar uses a binary format for headers, which makes its archives
easy to read on the computer that created it, but hard on other
architectures where things like byte ordering come into play.

Not really. ...anymore.

It's a fixed-width ascii header that's the same on all platforms, since,
oh... 4BSD? An ar archive of text files is a text file:

|!<arch>
|foo.txt/ 1143420083 1000 100 100644 4 `
|foo
|bar.txt/ 1143420086 1000 100 100644 4 `
|bar


The headers are small, which is helpful when you have a lot of
tiny files in the archive, and the archive resides on a disk.

Yeah, the headers are still small, each being one line 59 characters
wide.

Tar headers are large. Each header fills a 512-byte sector.
Files' contents are also padded, so that each files' header is
always aligned with the start of a tape sector. The headers
also contain checksums, so that it's possible to salvage some
files from a damaged tape.

Unless you do something moronic like compress the whole archive as one
big lump of data. But no-one would ever do that, right? Heh, almost my
whole reply, composed before i read the above paragraph, was a lengthy
description of the tar format, including an illustrated dump of a tar
file containing the same two files as the ar file above. Seems kind of
empty now that i've deleted it.

Seriously, someone should build a compress-each-file extension on top of
the tar format.

If your tape drive's sectors aren't 512 bytes, then it's possible
to tell the tar utility to use a "blocking" factor; i.e., multiple
512-byte sectors are ganged together to form larger physical
sectors.

So that's basically it. Tar archives are more portable,

Each format has its own history of unportability. Ar is mostly just more
obscure now.

more resiliant when damage occurs, and can handle odd block sizes.
Ar archives are easier to access and more compact.
.



Relevant Pages

  • Re: Tar output mode for installworld
    ... file1 uname=root gname=wheel ... In particular, tar requires ... interesting to extend the tar format with a "whiteout" ... tar archives as well. ...
    (freebsd-hackers)
  • Re: From the LuxAsm list.
    ... > therefore Luxasm uses the TIS 1.2 ELF format, which, to my knowledge, ... kind of _archive object code collection_ format I'm referring to...how they ... this actually is also an implicit "import" from the "librarian" ... dealing with multiple archives should be allowed ...
    (alt.lang.asm)
  • Re: cvs commit: src/usr.bin/tar Makefile bsdtar.1 bsdtar.c bsdtar.h bsdtar_platform.h matching.c rea
    ... the last official spec for tar. ... extensions even when not absolutely required. ... format won't use SUSv3 extensions just to store atime/ctime ... and some cpio archives. ...
    (freebsd-current)
  • Re: FreeBSD tar errors on valid empty tar.gz
    ... returns an error and generates a 0-byte tgz; as previously shown, BSD tar in 6.3 treats that as an empty archive, which seems reasonable, whereas gtar feeds it to gzip which generates an error: ... It turns out that empty archives are a tricky case. ... when it tried to determine the format. ...
    (freebsd-stable)
  • Re: Odysseus update, change in file storage
    ... necessarily also change relative message offsets in the TOC)? ... they may need to be broken into smaller mailboxes. ... The definitive description of the Zip format is ... then "extended" zip archives ...
    (comp.mail.eudora.mac)