From owner-cvs-all@FreeBSD.ORG Tue Jun 19 04:20:58 2007 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5239516A421; Tue, 19 Jun 2007 04:20:58 +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 2809413C457; Tue, 19 Jun 2007 04:20:57 +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 l5J4KvH7015944; Mon, 18 Jun 2007 21:20:57 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <467759A9.9040602@freebsd.org> Date: Mon, 18 Jun 2007 21:20:57 -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: Bruce Evans References: <200706180036.l5I0asac023540@repoman.freebsd.org> <4675DFC8.8060108@freebsd.org> <46760F7A.8020209@freebsd.org> <20070618195605.J43008@delplex.bde.org> In-Reply-To: <20070618195605.J43008@delplex.bde.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, Colin Percival Subject: Re: cvs commit: src/lib/libarchive archive_read_open_fd.c archive_read_open_filename.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2007 04:20:58 -0000 Bruce, Thanks for your explanation of the status quo. It sounds like lseek() is basically broken by design for anything that isn't a disk or a pipe. That's disappointing. It sounds like the best bsdtar can do is to only use the lseek() optimization if S_ISREG(). > Thus lseek() succeeds bogusly for amlmost all device files except > disks, including tapes. > Tape devices should probably work similarly -- reject offsets that they > can't handle at i/o time. This might be all offsets except 0. You advocate having the lseek() call succeed and the following read() call fail? I don't see how any application could recover from that. (bsdtar recovers from a failed seek, including ESPIPE, by just reading and discarding data; a failed read is a much more serious problem). >> The basic problem is that an lseek() call to a tape >> drive returns success exactly as if it worked. > > Because lseek() doesn't go anywhere near the device driver. > I think it is correct for lseek() to have no physical effect > until i/o time. No physical effect is a nice optimization, but it seems a bit odd for the driver to have no input into whether a particular lseek() request is acceptable. Many devices can do relative but not absolute seeks. Tim Kientzle