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