From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 20 14:04:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 85B291065672; Sun, 20 Nov 2011 14:04:50 +0000 (UTC) Date: Sun, 20 Nov 2011 14:04:50 +0000 From: Alexander Best To: Tim Kientzle Message-ID: <20111120140450.GA62286@freebsd.org> References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de> <20111117002438.GA55931@freebsd.org> <201111172055.pAHKtZso061118@triton8.kn-bremen.de> <20111118203122.GA9508@freebsd.org> <20111120124034.GA54811@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <20111120124034.GA54811@freebsd.org> Cc: freebsd-hackers@freebsd.org, Juergen Lock Subject: Re: easy way to determine if a stream or fd is seekable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 14:04:50 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun Nov 20 11, Alexander Best wrote: > On Sat Nov 19 11, Tim Kientzle wrote: > > > > On Nov 18, 2011, at 12:31 PM, Alexander Best wrote: > > > > > On Fri Nov 18 11, Tim Kientzle wrote: > > >> > > >> Take a look at > > >> > > >> http://libarchive.googlecode.com/svn/trunk/libarchive/archive_read_open_filename.c > > >> > > >> Especially the comments about detecting "disk-like" devices. > > >> I rewrote a bunch of this code to introduce an explicit > > >> notion of "strategy" so that we could optimize access > > >> to a variety of different devices. > > >> > > >> This code has a notion of "disk-like" file descriptors and > > >> some optimizations for such. There are some comments > > >> in there outlining similar optimizations that could be made > > >> for "tape-like" or "socket-like" devices. > > > > > > great you posted that file as reference. i believe most of the stuff done there > > > should actually be done within lseek(). > > > > Libarchive runs on a lot of systems other than FreeBSD. > > FreeBSD is not the only Unix-like system with this issue, > > so that code isn't going to go out of libarchive regardless. > > > > If you think those same ideas can be used in dd or hd > > to speed them up, please send your patches. > > i'm on it. ;) i'll send in the patches in a few days. > > > > > The key point: You cannot unconditionally call lseek() > > to skip over data. Instead, treat lseek() as an optimization > > that can be used under some circumstances. The > > question then becomes one of figuring out when > > that optimization can be enabled. > > ...however more importantly imo is that we fix the lseek(2) man page. i'm > adding a CAVEATS section, which includes some wording from the POSIX > definition, regarding the fact that lseek()'s behavior on devices that don't > support seeking is undefined or better: one cannot expect lseek() to return > an error, if the underlying device doesn't support seeking. so...any thoughts regarding this man page patch? cheers. alex i was also wondering, wether the limits of lseek() - being, it cannot guarantee that s seek operation was actually successful - also apply to all of the libc functions in the fseek(3) man page, being: fseek(), ftell(), rewind(), fgetpos(), fsetpos(), fseeko() and ftello(). if that is the case, a similar not should also be added to the fseek(3) man page, imo. > > cheers. > alex > > > > > Tim --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="lseek2.diff" diff --git a/lib/libc/sys/lseek.2 b/lib/libc/sys/lseek.2 index 874c523..ae183ea 100644 --- a/lib/libc/sys/lseek.2 +++ b/lib/libc/sys/lseek.2 @@ -28,7 +28,7 @@ .\" @(#)lseek.2 8.3 (Berkeley) 4/19/94 .\" $FreeBSD$ .\" -.Dd April 5, 2007 +.Dd November 20, 2011 .Dt LSEEK 2 .Os .Sh NAME @@ -114,10 +114,6 @@ If data is later written at this point, subsequent reads of the data in the gap return bytes of zeros (until data is actually written into the gap). .Pp -Some devices are incapable of seeking. -The value of the pointer -associated with such a device is undefined. -.Pp A .Qq hole is defined as a contiguous range of bytes in a file, all having the value of @@ -197,12 +193,28 @@ is associated with a pipe, socket, or FIFO. The .Fn lseek system call is expected to conform to -.St -p1003.1-90 . +.St -p1003.1-2008 . +.Pp +The +.Dv SEEK_HOLE +and +.Dv SEEK_DATA +directives, along with the +.Er ENXIO +error, are extensions to the specification. .Sh HISTORY The .Fn lseek function appeared in .At v7 . +.Sh CAVEATS +If +.Nm +is operating on a device, which is incapable of seeking, +it will request the seek operation and complete successfully. +The value of the pointer associated with such a device is undefined. +Device types which can be incapable of seeking include, +but are not limited to, tape drives. .Sh BUGS This document's use of .Fa whence --XsQoSWH+UP9D9v3l--