From owner-freebsd-arch Wed Jul 10 0:27:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 855DB37B400 for ; Wed, 10 Jul 2002 00:27:10 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D609B43E4A for ; Wed, 10 Jul 2002 00:27:09 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g6A7Quwr006313; Wed, 10 Jul 2002 00:27:00 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200207100727.g6A7Quwr006313@gw.catspoiler.org> Date: Wed, 10 Jul 2002 00:26:56 -0700 (PDT) From: Don Lewis Subject: Re: Package system flaws? To: tlambert2@mindspring.com Cc: archie@dellroad.org, dnelson@allantgroup.com, dan@FreeBSD.ORG, des@ofug.org, wes@softweyr.com, arch@FreeBSD.ORG In-Reply-To: <3D2BD2A7.F77DDB93@mindspring.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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