From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 17 09:59:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1AE8F106566C; Thu, 17 Nov 2011 09:59:51 +0000 (UTC) Date: Thu, 17 Nov 2011 09:59:51 +0000 From: Alexander Best To: Tim Kientzle Message-ID: <20111117095951.GA34444@freebsd.org> References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de> <20111117002438.GA55931@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org 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 09:59:51 -0000 On Wed Nov 16 11, Tim Kientzle wrote: > > On Nov 16, 2011, at 4:24 PM, Alexander Best wrote: > > > 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? > > There was a version of bsdtar that made the mistake of assuming > lseek() would return an error. > > lseek() on a tape drive does not return an error, nor does it > actually do anything. > > 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. dealing with tape drives wouldn't be that difficult. there's code in dd(1) e.g. that identifies a file argument as D_TAPE or !D_TAPE via an ioctl() call. if tapes are the only devices types that have issues with lseek(), this could easily be dealt with. i'll take a look at the bsdtar commit logs to find out where the exact problems were. however i vote that the lseek(2) and also fseek(3) should have their "BUGS" section extended with a description for the issue(s) that exist. might the problem with lseek() be related to this bug report? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60313 cheers. alex ps: since i've never worked with tape: what file type does it identify as? character special file, or block special file, or ...? > > Tim