cvs commit: src/lib/libarchive archive_read_open_fd.c
kientzle at freebsd.org
Tue Jun 19 04:20:58 UTC 2007
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
> 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
>> 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.
More information about the cvs-all