From owner-cvs-src@FreeBSD.ORG Mon Jun 18 04:52:11 2007 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 745B916A400; Mon, 18 Jun 2007 04:52:11 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4D2AA13C44B; Mon, 18 Jun 2007 04:52:11 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.222] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id l5I4qAH7007880; Sun, 17 Jun 2007 21:52:10 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <46760F7A.8020209@freebsd.org> Date: Sun, 17 Jun 2007 21:52:10 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Percival References: <200706180036.l5I0asac023540@repoman.freebsd.org> <4675DFC8.8060108@freebsd.org> In-Reply-To: <4675DFC8.8060108@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libarchive archive_read_open_fd.c archive_read_open_filename.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2007 04:52:11 -0000 Colin Percival wrote: > Tim Kientzle wrote: > >> I fear I'll have to avoid seeks ... tape drives on >> FreeBSD seem to return garbage from lseek(). > > Is there any reason why the tape drivers can't be fixed? Since people are running into this problem today on 6.2, I'm planning to fix it where I can. :-/ The basic problem is that an lseek() call to a tape drive returns success exactly as if it worked. Daniel O'Connor recently sent me the following ktrace from bsdtar doing a tar -t of an uncompressed tar archive from his Tandberg TS400 connected to an Adaptec 29160 controller: 5378 bsdtar CALL lseek(0x3,0,0,0x1) 5378 bsdtar RET lseek 51200/0xc800 5378 bsdtar CALL lseek(0x3,0,0x2f800,0x1) 5378 bsdtar RET lseek 245760/0x3c000 Note that the second call returns a new file position that's exactly 0x2f800 bytes beyond the former file position, even though nothing has actually happened. I think any of the following would be reasonable behaviors: * lseek() could return ESPIPE ("illegal seek") * lseek() could return an unchanged file offset (indicating that the file position was unchanged by the attempted seek). * lseek() could return ENOTSUP ("unsupported operation") As I said though, I just don't know that code well enough to propose a fix. Tim Kientzle