Date: Mon, 18 Jun 2007 21:20:57 -0700 From: Tim Kientzle <kientzle@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Colin Percival <cperciva@freebsd.org> Subject: Re: cvs commit: src/lib/libarchive archive_read_open_fd.c archive_read_open_filename.c Message-ID: <467759A9.9040602@freebsd.org> In-Reply-To: <20070618195605.J43008@delplex.bde.org> References: <200706180036.l5I0asac023540@repoman.freebsd.org> <4675DFC8.8060108@freebsd.org> <46760F7A.8020209@freebsd.org> <20070618195605.J43008@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce, Thanks for your explanation of the status quo. It sounds like lseek() is basically broken by design for anything that isn't a disk or a pipe. That's disappointing. It sounds like the best bsdtar can do is to only use the lseek() optimization if S_ISREG(). > Thus lseek() succeeds bogusly for amlmost all device files except > disks, including tapes. > Tape devices should probably work similarly -- reject offsets that they > can't handle at i/o time. This might be all offsets except 0. You advocate having the lseek() call succeed and the following read() call fail? I don't see how any application could recover from that. (bsdtar recovers from a failed seek, including ESPIPE, by just reading and discarding data; a failed read is a much more serious problem). >> The basic problem is that an lseek() call to a tape >> drive returns success exactly as if it worked. > > Because lseek() doesn't go anywhere near the device driver. > I think it is correct for lseek() to have no physical effect > until i/o time. No physical effect is a nice optimization, but it seems a bit odd for the driver to have no input into whether a particular lseek() request is acceptable. Many devices can do relative but not absolute seeks. Tim Kientzle
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?467759A9.9040602>