Date: Wed, 10 Jul 2002 00:26:56 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: tlambert2@mindspring.com Cc: archie@dellroad.org, dnelson@allantgroup.com, dan@FreeBSD.ORG, des@ofug.org, wes@softweyr.com, arch@FreeBSD.ORG Subject: Re: Package system flaws? Message-ID: <200207100727.g6A7Quwr006313@gw.catspoiler.org> In-Reply-To: <3D2BD2A7.F77DDB93@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 Jul, Terry Lambert wrote:
> Archie Cobbs wrote:
>> Dan Nelson writes:
>> > > tar has a limitation which I've encountered: suppose you have a port
>> > > that installs a man page with lots of references (i.e., hard linked
>> > > files with different names with a single underlying file). Then in
>> > > tar format, you get the same file copied N times. If we used cpio
>> > > instead (for example) then it "knows" how to handle hard links.
>> >
>> > Tar handles hardlinks just fine.
>>
>> Oops, you're right... don't know how I got that idea in my head.
>> OK me shut up now :-)
>
> It's a GNU tar thing; real tar acts the way you say, and also has
> problems with holey files, etc.. We used to use cpio for nearly
> everything back in the old days at Century Software (mid-late 80's).
tar has handled hard links properly for a long time. My copy of the 7th
Edition manual documents tar's "l" option:
tells tar to complain if it cannot resolve all of the links to
the files dumped. If this is not specified, no error messages
are printed.
While this doesn't directly indicate that tar does the restores one copy
of the file and all the links, it certainly suggests this possibility.
The 1985 edition of the Masscomp version of the Unix Programmers Manual
documents the format of the tar(5) header.
#define NAMSIZ 100
struct header {
char name[NAMSIZ];
char mode[8];
char uid[8];
char gid[8];
char size[8];
char mtime[12];
char chksum[8];
char linkflag;
char linkname[NAMSIZ];
}
In the description is says:
_Name_ is a null-terminated string. ... _Size_ is the size of
the file in bytes. Links and symbolic links are dump with this
field specified as zero. ... _Linkflag_ is ASCII '0' if the
file is "normal" or a special file, ASCII '1' if it is an hard
link, and ASCII '2' if it is a symbolic link. The name
linked-to, if any, is in _linkname_, with a trailing null. ...
The first time a given i-node number is dumped, it is dumped
as a regular file. The second and subsequent times, it is
dumped as a link instead. Upon retrieval, if a link entry
is retrieved, but not the file it was linked to, an error
message is printed and the tape must be manually rescanned
to retrieve the linked-to file.
Back in those days I prefered tar's interface to cpio's, but I had to
use cpio a lot because it had larger filename length limits.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207100727.g6A7Quwr006313>