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>