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