From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 17 00:24:38 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1E85A1065670; Thu, 17 Nov 2011 00:24:38 +0000 (UTC) Date: Thu, 17 Nov 2011 00:24:38 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20111117002438.GA55931@freebsd.org> References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111116232152.GC21793@britannica.bec.de> Subject: Re: easy way to determine if a stream or fd is seekable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 00:24:38 -0000 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