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

[Tim Kientzle]

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