Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Nov 2011 00:24:38 +0000
From:      Alexander Best <arundel@freebsd.org>
To:        freebsd-hackers@freebsd.org
Subject:   Re: easy way to determine if a stream or fd is seekable
Message-ID:  <20111117002438.GA55931@freebsd.org>
In-Reply-To: <20111116232152.GC21793@britannica.bec.de>
References:  <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111117002438.GA55931>