easy way to determine if a stream or fd is seekable
Alexander Best
arundel at freebsd.org
Thu Nov 17 00:24:38 UTC 2011
On Thu Nov 17 11, Joerg Sonnenberger wrote:
> On Wed, Nov 16, 2011 at 01:14:28PM +0000, Alexander Best wrote:
> > On Wed Nov 16 11, Joerg Sonnenberger wrote:
> > > On Tue, Nov 15, 2011 at 08:24:50PM +0000, Alexander Best wrote:
> > > > one of the things i'm missing is an easy way to determine, whether a stream or
> > > > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are
> > > > performing so much stuff just to find out if this is the case, and they still
> > > > are doing a very poor job.
> > >
> > > Isn't the primary issue that FreeBSD doesn't properly report errors for
> > > lseek(2)? I think you should start from that and not hack around the
> > > fallout...
> >
> > what do you mean? lseek(2) returns -1, when the file descriptor is not
> > seekable. i fired lseek(2) at all sorts of file types (dir, sockets, ...)
> > and it always returned the correct result.
>
> If that were the case, you wouldn't need your flag to detect seek
> support. But e.g. some devices silently ignore seek requests without
> reporting errors. At least that is what I remember from the last time
> this has brought up.
this is the first time i hear about problems with seek requests. would be nice
to see some examples cases. was this discussed on the mailinglists? or
submitted as a problem report?
even if lseek(2) would always work, it would be overhead. there's no need to
test a file operand against seeking, because we can derive that from its type.
a file operand that isn't a pipe, fifo or socket IS seekable. i consider
running S_ISSEEK(m) much more intuitive than first opening a file, saving its
filedescriptor, dealing with errors, running lseek(2) with a zero offset
argument (which appears to be very hackish), dealing with lseek(2) errors and
finally evaluating lseek(2)'s return value.
also the way of checking, whether a file operand is seekable via lseek(2) as
always existed and people don't seem to understood that. hexdump(1) and dd(1)
weren't written by amateurs -- still they aren't using lseek(2) on their file
operand or aren't doing it correctly. so i believe developers should be given a
more intuitive way to check for the ability to seek on a given file operand.
S_ISSEEK(m) seems to be a very good solution from my point of view.
cheers.
alex
>
> Joerg
More information about the freebsd-hackers
mailing list