Why fseek causes a read()?

[Konstantin Kharlamov]

Okay, I reported a bug https://sourceware.org/bugzilla/show_bug.cgi?id=25497

On 01.02.2020 00:28, Konstantin Kharlamov wrote:
> On 31.01.2020 22:16, Al wrote:
>> It used to be that the documentation for seek/lseek and fseek suggested if a device was not capable of direct positioning, that the
>> library routines would try to chew through the intervening space via a (or many) read() system call(s).
>>
>> I wouldn't want to disable that without understanding the consequences. Your experience suggests that that logic may not be functioning correctly, but I wouldn't discard it lightly.  It may be better to figure out if it is broken, and if so fix it.
>>
>> I haven't gone through that code in the past, so I am sure if it has changed.
>>
>> Block devices should generally be seekable, but not all are.
> 
> But if the device is not seekable, wouldn't `lseek()` (which is used inside fseek() just before calling the read()) just return a -1? So glibc could check that, and only in case of -1 to fall back to repositioning with read().