From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 21 12:07:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id B14381065675; Mon, 21 Nov 2011 12:07:51 +0000 (UTC) Date: Mon, 21 Nov 2011 12:07:51 +0000 From: Alexander Best To: Benjamin Kaduk Message-ID: <20111121120751.GA85679@freebsd.org> References: <201111172055.pAHKtZso061118@triton8.kn-bremen.de> <20111118203122.GA9508@freebsd.org> <20111120124034.GA54811@freebsd.org> <20111120140450.GA62286@freebsd.org> <20111120142131.GA64913@freebsd.org> <4eca40f5.fvA0Xb1G9w+wuGj6%perryh@pluto.rain.com> <20111121110206.GA63744@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <20111121110206.GA63744@freebsd.org> Cc: freebsd-hackers@freebsd.org, perryh@pluto.rain.com, nox@jelal.kn-bremen.de 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: Mon, 21 Nov 2011 12:07:51 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon Nov 21 11, Alexander Best wrote: > On Mon Nov 21 11, Benjamin Kaduk wrote: > > On Mon, 21 Nov 2011, perryh@pluto.rain.com wrote: > > > > >Alexander Best wrote: > > > > > >>here's a revised patch. > > >>... > > >>+.Sh CAVEATS > > >>+If the > > >>+.Fn lseek > > >>+system call is operating on a device, which is incapable of seeking, > > >>+it will request the seek operation and complete successfully. > > > > > >I think it would be better without the first comma (after "device"). > > > > Definitely. > > > > Also, > > > > +.Sh CAVEATS > > +If the > > +.Fn lseek > > +system call is operating on a device, which is incapable of seeking, > > +it will request the seek operation and complete successfully. > > > > I would prefer something like "request the seek operation and return as if > > the seek was successful, even though no seek was performed." > > > > +The value of the pointer associated with such a device is undefined. > > > > "Which pointer?" That it is "the file offset" was clear from context > > where this line was moved from, but is no longer, here. > > > > +Device types which can be incapable of seeking include, > > +but are not limited to, tape drives. > > > > This is an awkward phrasing; perhaps just "Many tape drives are incapable > > of seeking and can trigger this bug."? > > this is too limited. this suggests that only certain tape drives won't seek > after a successfull return of lseek(). as i mentioned beforehand, this is also > the case with device with insertable media, such as dvd and blue-ray drives. > here lseek() will sucessfully return, without a media inserted. > > i'll rephrase the whole patch and will submit a revised version. i think a > reference to POLA, would also be a good idea, as suggested by perry@ here's a revised patch. cheers. alex > > thanks for all the suggestions. > > cheers. > alex > > > > > -Ben Kaduk --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="lseek.2.diff" diff --git a/lib/libc/sys/lseek.2 b/lib/libc/sys/lseek.2 index 874c523..bcd9d20 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 21, 2011 .Dt LSEEK 2 .Os .Sh NAME @@ -113,10 +113,9 @@ of the existing end-of-file of the file. 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. +However, the +.Fn lseek +system call does not, by itself, extend the size of a file. .Pp A .Qq hole @@ -197,13 +196,43 @@ 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 that specification. .Sh HISTORY The .Fn lseek function appeared in .At v7 . .Sh BUGS +If the +.Fn lseek +system call is operating on a device which is incapable of seeking, +it will request the seek operation and return successfully, +even though no seek was performed. +Because the +.Ar offset +argument will be stored in the file descriptor of that device, +there is no way to verifying/falsify the seek operation afterwards +(e.g. using the +.Fn ftell +function). +Device types which are known to be incapable of seeking include +tape drives. +.Pp +The +.Fn lseek +system call will not detect, whether media are present in changeable +media devices, such as DVD or Blue-ray devices. +A requested seek operation will therefore return sucessfully in case +of an uninserted medium. +.Pp This document's use of .Fa whence is incorrect English, but is maintained for historical reasons. --ew6BAiZeqk4r7MaW--