easy way to determine if a stream or fd is seekable

Benjamin Kaduk kaduk at MIT.EDU
Tue Nov 22 04:30:03 UTC 2011


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,

Ben


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


More information about the freebsd-hackers mailing list