Date: Sun, 17 Jun 2007 21:52:10 -0700 From: Tim Kientzle <kientzle@freebsd.org> To: Colin Percival <cperciva@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libarchive archive_read_open_fd.c archive_read_open_filename.c Message-ID: <46760F7A.8020209@freebsd.org> In-Reply-To: <4675DFC8.8060108@freebsd.org> References: <200706180036.l5I0asac023540@repoman.freebsd.org> <4675DFC8.8060108@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Colin Percival wrote:
> Tim Kientzle wrote:
>
>> I fear I'll have to avoid seeks ... tape drives on
>> FreeBSD seem to return garbage from lseek().
>
> Is there any reason why the tape drivers can't be fixed?
Since people are running into this problem today
on 6.2, I'm planning to fix it where I can. :-/
The basic problem is that an lseek() call to a tape
drive returns success exactly as if it worked.
Daniel O'Connor recently sent me the following
ktrace from bsdtar doing a tar -t of an uncompressed
tar archive from his Tandberg TS400 connected to an
Adaptec 29160 controller:
5378 bsdtar CALL lseek(0x3,0,0,0x1)
5378 bsdtar RET lseek 51200/0xc800
5378 bsdtar CALL lseek(0x3,0,0x2f800,0x1)
5378 bsdtar RET lseek 245760/0x3c000
Note that the second call returns a new file position
that's exactly 0x2f800 bytes beyond the former file
position, even though nothing has actually happened.
I think any of the following would be reasonable behaviors:
* lseek() could return ESPIPE ("illegal seek")
* lseek() could return an unchanged file offset
(indicating that the file position was unchanged by
the attempted seek).
* lseek() could return ENOTSUP ("unsupported operation")
As I said though, I just don't know that code well
enough to propose a fix.
Tim Kientzle
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46760F7A.8020209>