easy way to determine if a stream or fd is seekable

[Alexander Best]

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
-------------- next part --------------
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