easy way to determine if a stream or fd is seekable

[Alexander Best]

On Mon Nov 21 11, Alexander Best wrote:
> On Mon Nov 21 11, Benjamin Kaduk wrote:
> > On Mon, 21 Nov 2011, perryh at pluto.rain.com wrote:
> > 
> > >Alexander Best <arundel at freebsd.org> 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
-------------- next part --------------
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.