easy way to determine if a stream or fd is seekable

[Alexander Best]

On Fri Nov 18 11, Tim Kientzle wrote:
> 
> On Nov 17, 2011, at 12:55 PM, Juergen Lock wrote:
> 
> >> 
> >> After a few experiments, bsdtar stopped using lseek() on
> >> FreeBSD for anything other than regular files and block
> >> devices.   I believe there are other things that do support
> >> seeking, but I don't believe there is an accurate mechanism
> >> for determining whether lseek() is correctly supported.
> > 
> > Ah is that the reason why my patch never made it into FreeBSD 9?
> > I'm talking about this thread, where I also commented on seeking
> > on tape:
> > 
> > 	http://docs.freebsd.org/cgi/mid.cgi?20100220101724.GA26604
> > 	(Re: "tar tfv /dev/cd0" speedup patch)
> > 
> > 	entire thread here:
> > 	http://markmail.org/message/nfznipqik3tuhbqp
> > 
> > Cheers,
> > 	Juergen (who would still like to see a faster "tar tfv /dev/cd0"... :)
> 
> I would like to see that as well.
> 
> 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(). if userspace applications have to
determine between file types they're operating on we're back to in the pre-unix
days. ;)

cheers.
alex

maybe support for block special files could completely be dropped, since
freebsd seems to have entirely switched to character special files?

> 
> Cheers,
> 
> Tim
>