From owner-freebsd-bugs Sun Apr 2 0:20:25 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 3A71C37B9F4 for ; Sun, 2 Apr 2000 00:20:23 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id AAA56150; Sun, 2 Apr 2000 00:20:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Sun, 2 Apr 2000 00:20:02 -0800 (PST) Message-Id: <200004020820.AAA56150@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Anatoly Vorobey Subject: Re: bin/17619: pax cannot read all tar files created by tar. Reply-To: Anatoly Vorobey Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/17619; it has been noted by GNATS. From: Anatoly Vorobey To: Sheldon Hearn , marcolz@stack.nl Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/17619: pax cannot read all tar files created by tar. Date: Sun, 2 Apr 2000 10:13:31 +0000 On Wed, Mar 29, 2000 at 02:50:03AM -0800, Sheldon Hearn wrote: > The following reply was made to PR bin/17619; it has been noted by GNATS. > > From: Sheldon Hearn > To: marcolz@stack.nl > Cc: FreeBSD-gnats-submit@FreeBSD.ORG > Subject: Re: bin/17619: pax cannot read all tar files created by tar. > Date: Wed, 29 Mar 2000 12:41:38 +0200 > > On Mon, 27 Mar 2000 14:57:39 +0200, marcolz@stack.nl wrote: > > > When trying to read a tar file created by GNU-tar or Solaris's tar, > > pax asks for another archive. It seems to misinterpret the tar-header. > > Some sizes of tar's will be handled just right, others don't. I looked into this. pax thinks tar archives should end with at least 2 blocks of zero (i.e. 1024 zeroed bytes *after* the file ends). In the example provided, GNU tar creates only one such block, and pax thinks it must read another one which is not there, so it asks for the next volume. I don't know which one of them is right. In fact, I tried to look into GNU tar's code for creating archives, and couldn't understand where it creates even one block and what governs its behavior. The code there is extremely unreadable. pax can be made happy by this: --- tar.h.orig Sun Apr 2 10:10:11 2000 +++ tar.h Sun Apr 2 10:10:19 2000 @@ -44,7 +44,7 @@ #define CHK_LEN 8 /* length of checksum field */ #define TNMSZ 100 /* size of name field */ #ifdef _PAX_ -#define NULLCNT 2 /* number of null blocks in trailer */ +#define NULLCNT 1 /* number of null blocks in trailer */ #define CHK_OFFSET 148 /* start of checksum field */ #define BLNKSUM 256L /* sum of checksum field using ' ' */ #endif /* _PAX_ */ This shouldn't create any adverse effects, and appears to work on all archives created by GNU tar; however, pax will also add one trailer block rather than two to its archives after the patch. The relevant code which uses this constant is in the tar_trail() function in tar.c . -- Anatoly Vorobey, mellon@pobox.com http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message