easy way to determine if a stream or fd is seekable

[Alexander Best]

On Mon Nov 21 11, Benjamin Kaduk wrote:
> On Mon, 21 Nov 2011, Alexander Best wrote:
> 
> >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.
> 
> % 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
> % @@ -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,
> 
> This sentence assumes more familiarity with file i/o implementation than 
> seems prudent.  Perhaps "stored in the file descriptor of that device and 
> thus used for future queries" or something similar?
> 
> % +there is no way to verifying/falsify the seek operation afterwards
> 
> "verifying" is incorrect, here.  Just "verify" would work, but the combo 
> "verify/falsify" doesn't feel quite right.
> I guess I want "no way to confirm success of the seek operation" (no 
> 'afterwards').
> 
> % +(e.g. using the
> % +.Fn ftell
> % +function).
> % +Device types which are known to be incapable of seeking include
> % +tape drives.
> 
> "most"?  I think someone said that certain (old) drives could actually 
> seek under some circumstances.
> 
> % +.Pp
> % +The
> % +.Fn lseek
> % +system call will not detect, whether media are present in changeable
> % +media devices, such as DVD or Blue-ray devices.
> 
> The first comma is bogus; the second comma could be removed, and probably 
> should be.
> Also, "Blu-ray" has no 'e' (but apparently is capitalized in that way).
> 
> % +A requested seek operation will therefore return sucessfully in case
> % +of an uninserted medium.
> 
> s/in case of an uninserted medium/when no medium is present/.
> 
> Thanks for the fixups,

thanks for your suggestions. i included some of them into the patch and also
added a few stuff myself. maybe you could have a look at the problem report
i submitted [1] and post a followup mail, what you think. this worked quite
well the last time, in case of the du(1) man page patch, imo. ;)

cheers.
alex

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=162765

> 
> Ben
> 
> 
> % +.Pp
> %  This document's use of
> %  .Fa whence
> %  is incorrect English, but is maintained for historical reasons.