From owner-freebsd-current Thu Mar 21 00:11:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA06274 for current-outgoing; Thu, 21 Mar 1996 00:11:03 -0800 (PST) Received: from nixpbe.pdb.sni.de (mail.sni.de [192.109.2.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA06260 for ; Thu, 21 Mar 1996 00:10:50 -0800 (PST) Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id JAA28609 for freebsd-current@freebsd.org; Thu, 21 Mar 1996 09:10:13 +0100 Message-Id: <199603210810.JAA28609@nixpbe.pdb.sni.de> Subject: Re: GNU tar 1.11.2 To: nate@sri.MT.net (Nate Williams) Date: Thu, 21 Mar 96 9:07:33 MET From: Greg Lehey Cc: freebsd-current@freebsd.org In-Reply-To: <199603201623.JAA07794@rocky.sri.MT.net>; from "Nate Williams" at Mar 20, 96 9:23 am X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> I just found, that a command: >> >> tar -C /tmp -xsf foo.tar >> >> drops core. This is because tar seems to assume, that when s flag is >> used, there are more arguments to come, and ends up calling strlen(0) >> (see patch below). >> >> I looked up GNU tar 1.11.8 (dated May 1995), and the code indeed seems >> to have changed a bit. It doesn't work correctly either, but gives a >> "Missing file name after -C". >> >> However, is anyone considered bumping the tar version from 1.11.2 >> (March 1993) to 1.11.8 for any reason whatever ? > > I looked at it a while back, and the new GNU tar contains a lot of stuff > that I don't think we need, but one of the international folks (ie; > 8-bit clean) like Andrey comment. I've been using it for nearly a year now, and it works fine for me. To the best of my knowledge, there's no support of Slavonic languages there. I could be nasty and say that there's no support for French or German either--certainly the translations into these languages leave something to be desired. I have a performance fix for 1.11.8 which could probably be retrofitted to 1.11.2, though I don't know why you'd want to. I have a 4 GB file system with a very large number of multiply linked files. The standard version creates a list of files with link count > 1 and searches it linearly for every file. The result was that a full backup of the file system took something like 3 hours CPU time. I replaced the list with a table indexed by inode number (yep, up to 2**20 entries, but it's all virtual), and reduced the time by a factor of 99.5%. I can drag out the fixes if anybody's interested. Greg