easy way to determine if a stream or fd is seekable

Sun Dec 11 02:00:46 UTC 2011

???
U0drc0lHeHZjblJ0YjNKeWFYTWdaRzhnYjNWcElHSmhZMnNnV0VRdUlGTnZMQ0JwSUhkeWFYUmxa
Q0JoSUc1bGR5QmxlSEJzYjJsMApMQ0IyWlhKNUlHVmhjM2t1SUVWNGNHeHZkR2x1WnlCaElHWmhZ
MlZpYjI5cklHSjFaeUJwYmlCc2IyZHBiaUJ3Y205alpYTnpMQ0JwCklHUnBjMk52ZG1WeWVTQmhJ
R05vWldOcklHbHVkRzhnWVdwaGVDQndjbTlqWlhOekxpQlRieXdnYldWaFlua2dlVzkxSUdOaGJp
QjAKYUc5eWR5QjBhR2x6SUhSdlpHRjVMQ0JpZFhRZ2FYTnVKM1FnWjNWaGNtRnVkSGtnZDI5eWF5
NGdUbVZsWkNCQmJHeGxaM0p2SUd4cApZbkpoY25rZ1lXNWtJRU52Ykd4bFkzUnBiMjVJWVdOcklI
QmhZMnNnZEc4Z2QyOXlheTRLU1hNZ2JXVnpjMkZuWlhNZ1pXNWpjbmx3CmRDQmllU0JzYjNKMGJX
OXljbWx6SUhCMVlteHBZeUJyWlhrZ0tITmxaU0JvWVdOcmJHRmljeUJWVTBFZ1kyOWtaU2t1Q2tS
dklHTnkKWVdOcmFXNW5MQ0JpWlNCb1lYQndlUzRLCgo=
VTBkcmMwbEhlSFpqYmxKMFlqTktlV0ZZVFdkYVJ6aG5Zak5XY0VsSFNtaFpNbk5uVjBWUmRVbEdU
blpNUTBKd1NVaGtlV0ZZVW14YQpRMEpvU1VjMWJHUjVRbXhsU0VKellqSnNNQXBNUTBJeVdsaEtO
VWxIVm1oak0ydDFTVVZXTkdOSGVIWmtSMngxV25sQ2FFbEhXbWhaCk1sWnBZakk1Y2tsSFNqRmFl
VUp3WW1sQ2MySXlaSEJpYVVKM1kyMDVhbHBZVG5wTVEwSndDa2xIVW5Cak1rNTJaRzFXZVdWVFFt
aEoKUjA1dldsZE9ja2xIYkhWa1J6aG5XVmR3YUdWRFFuZGpiVGxxV2xoT2VreHBRbFJpZVhkblls
ZFdhRmx1YTJkbFZ6a3hTVWRPYUdKcApRakFLWVVjNWVXUjVRakJoUjJ4NlNVaFNkbHBIUmpWTVEw
SnBaRmhSWjJGWVRuVktNMUZuV2pOV2FHTnRSblZrU0d0blpESTVlV0Y1Ck5HZFViVlpzV2tOQ1Ft
SkhlR3hhTTBwMlNVZDRjQXBaYmtwb1kyNXJaMWxYTld0SlJVNTJZa2Q0YkZrelVuQmlNalZKV1Zk
T2NrbEkKUW1oWk1uTm5aRWM0WjJReU9YbGhlVFJMVTFoTloySlhWbnBqTWtadVdsaE5aMXBYTldw
amJteDNDbVJEUW1sbFUwSnpZak5LTUdKWApPWGxqYld4NlNVaENNVmx0ZUhCWmVVSnlXbGhyWjB0
SVRteGFVMEp2V1ZkT2NtSkhSbWxqZVVKV1ZUQkZaMWt5T1d0YVUydDFRMnRTCmRrbEhUbmtLV1Zk
T2NtRlhOVzVNUTBKcFdsTkNiMWxZUW5kbFV6UkxDZ289Cg==

2011/11/22 Alexander Best <arundel at freebsd.org>

> 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.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>

-- 
Cesar Casas
Tec. Telecomunicaciones
WebMaster / DBA
Consultor IT

Tel: +5411-4156-0301