From owner-freebsd-bugs Wed Apr 5 23:50: 7 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 BBCD837B7E3 for ; Wed, 5 Apr 2000 23:50:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id XAA25798; Wed, 5 Apr 2000 23:50:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Wed, 5 Apr 2000 23:50:04 -0700 (PDT) Message-Id: <200004060650.XAA25798@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: Marc Olzheim Cc: freebsd-gnats-submit@freebsd.org Subject: Re: bin/17619: pax cannot read all tar files created by tar. Date: Thu, 6 Apr 2000 08:46:40 +0000 On Mon, Apr 03, 2000 at 10:20:54AM +0200, Marc Olzheim wrote: > > Bah. So what should be done in this case (assuming something needs > > to be done?). I can patch pax to accept one-block archives and > > yet produce correct archives - maybe that's the way to go? Given that > > the GNU tar maintainer had more than 8 years to think about it, he's > > obviously emotionally attached to one-trailing-block files and won't > > let them go ;) > > That seems like a good idea to me. See the attached patch. Tested, works fine. Maybe someone shall review/commit it? Index: tar.c =================================================================== RCS file: /freebsd/cvs/src/bin/pax/tar.c,v retrieving revision 1.13 diff -u -r1.13 tar.c --- tar.c 1999/08/27 23:14:47 1.13 +++ tar.c 2000/04/06 08:36:55 @@ -86,7 +86,7 @@ tar_endwr() #endif { - return(wr_skip((off_t)(NULLCNT*BLKMULT))); + return(wr_skip((off_t)(NULL_PUT*BLKMULT))); } /* @@ -104,7 +104,7 @@ tar_endrd() #endif { - return((off_t)(NULLCNT*BLKMULT)); + return((off_t)(NULL_PUT*BLKMULT)); } /* @@ -152,8 +152,14 @@ * NOT try to id a trailer during resync mode. During resync mode we * might as well throw this block out since a valid header can NEVER be * a block of all 0 (we must have a valid file name). + * + * A bug in GNU tar causes it to sometimes produce trailers with + * just one zero block. To handle this, we will put NULL_PUT + * blocks in our archives, but will expect NULL_EXPECT on reads. + * If there are actually two zero blocks, the second one will be + * skipped on the next next_head() call. */ - if (!in_resync && (++*cnt >= NULLCNT)) + if (!in_resync && (++*cnt >= NULL_EXPECT)) return(0); return(1); } Index: tar.h =================================================================== RCS file: /freebsd/cvs/src/bin/pax/tar.h,v retrieving revision 1.6 diff -u -r1.6 tar.h --- tar.h 1999/08/27 23:14:47 1.6 +++ tar.h 2000/04/06 08:32:28 @@ -44,7 +44,16 @@ #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 */ + +/* + * The USTAR format requires two null blocks to trail every file, yet + * GNU tar will sometimes produce tar files with only one. Hence the + * double standard. + */ + +#define NULL_PUT 2 /* num of blocks to put in trailer */ +#define NULL_EXPECT 1 /* num of blocks to expect there */ + #define CHK_OFFSET 148 /* start of checksum field */ #define BLNKSUM 256L /* sum of checksum field using ' ' */ #endif /* _PAX_ */ -- 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