Why fseek causes a read()?

Konstantin Kharlamov hi-angel@yandex.ru
Fri Jan 31 21:28:00 GMT 2020


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().



More information about the Libc-help mailing list