cvs commit: src/lib/libarchive archive_read_open_fd.c archive_read_open_filename.c

[Tim Kientzle]

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