easy way to determine if a stream or fd is seekable

Alexander Best arundel at freebsd.org
Sun Nov 20 12:40:34 UTC 2011


On Sat Nov 19 11, Tim Kientzle wrote:
> 
> On Nov 18, 2011, at 12:31 PM, Alexander Best wrote:
> 
> > On Fri Nov 18 11, Tim Kientzle wrote:
> >> 
> >> Take a look at 
> >> 
> >> http://libarchive.googlecode.com/svn/trunk/libarchive/archive_read_open_filename.c
> >> 
> >> Especially the comments about detecting "disk-like" devices.
> >> I rewrote a bunch of this code to introduce an explicit
> >> notion of "strategy" so that we could optimize access
> >> to a variety of different devices.
> >> 
> >> This code has a notion of "disk-like" file descriptors and
> >> some optimizations for such.  There are some comments
> >> in there outlining similar optimizations that could be made
> >> for "tape-like" or "socket-like" devices.
> > 
> > great you posted that file as reference. i believe most of the stuff done there
> > should actually be done within lseek().
> 
> Libarchive runs on a lot of systems other than FreeBSD.
> FreeBSD is not the only Unix-like system with this issue,
> so that code isn't going to go out of libarchive regardless.
> 
> If you think those same ideas can be used in dd or hd
> to speed them up, please send your patches.

i'm on it. ;) i'll send in the patches in a few days.

> 
> The key point:  You cannot unconditionally call lseek()
> to skip over data.  Instead, treat lseek() as an optimization
> that can be used under some circumstances.  The
> question then becomes one of figuring out when
> that optimization can be enabled.

...however more importantly imo is that we fix the lseek(2) man page. i'm
adding a CAVEATS section, which includes some wording from the POSIX
definition, regarding the fact that lseek()'s behavior on devices that don't
support seeking is undefined or better: one cannot expect lseek() to return
an error, if the underlying device doesn't support seeking.

cheers.
alex

> 
> Tim


More information about the freebsd-hackers mailing list