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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
