From owner-freebsd-bugs@FreeBSD.ORG Wed Jul 11 08:40:10 2007 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BB7216A41F for ; Wed, 11 Jul 2007 08:40:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id BA5A713C45B for ; Wed, 11 Jul 2007 08:40:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l6B8e98p030951 for ; Wed, 11 Jul 2007 08:40:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l6B8e9bY030950; Wed, 11 Jul 2007 08:40:09 GMT (envelope-from gnats) Date: Wed, 11 Jul 2007 08:40:09 GMT Message-Id: <200707110840.l6B8e9bY030950@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Bernd Luevelsmeyer Cc: Subject: Re: bin/106973: tar(1) cannot read own tape, but pax(1) can X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernd Luevelsmeyer List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2007 08:40:10 -0000 The following reply was made to PR bin/106973; it has been noted by GNATS. From: Bernd Luevelsmeyer To: bug-followup@FreeBSD.org Cc: Tim Kientzle Subject: Re: bin/106973: tar(1) cannot read own tape, but pax(1) can Date: Wed, 11 Jul 2007 10:36:49 +0200 This issue came up in the freebsd-stable mailing list. Tim Kientzle wrote in <46679117.5060909@freebsd.org> that the SCSI tape driver in 6.2 claims to be able to do lseek() while in fact it cannot. tar believes it and issues lseek() commands, whereupon things go bad. (Apparently, pax simply doesn't use lseek() commands, hence has no problems.) In <4675CD95.9040004@freebsd.org>, he published a patch that prevents tar from using lseek() commands. With this patch, tar works just fine for me again. However, IMHO this is only a workaround; really, the tape driver should not be lying about its capabilities. Here is the patch: --- archive_read_open_filename.c (revision 124) +++ archive_read_open_filename.c (working copy) @@ -165,6 +165,15 @@ struct read_file_data *mine = (struct read_file_data *)client_data; off_t old_offset, new_offset; + /* + * Workaround for broken tape interfaces that don't support + * seek(), but return success if you ask them to seek(). This + * also, of course, slows down archive scanning significantly + * on devices that can seek. Yuck. + */ + if (S_ISCHR(mine->st_mode) || S_ISBLK(mine->st_mode)) + return (0); + /* Reduce request to the next smallest multiple of block_size */ request = (request / mine->block_size) * mine->block_size; /* I request that the PR's class be changed to kernel (since the error is in a driver).