On Mon, Jun 18, 2007 at 09:20:57PM -0700, Tim Kientzle wrote:
> into whether a particular lseek() request is acceptable.
> Many devices can do relative but not absolute seeks.
Ah, I understand the problem and it is not related to drivers but
misunderstanding what lseek does. lseek changes _virt
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 bogusl
On Sun, 17 Jun 2007, Tim Kientzle wrote:
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?
lseek(2) succeeds for almost all file types except
On Monday 18 June 2007 17:54, Alfred Perlstein wrote:
> > * lseek() could return ENOTSUP ("unsupported operation")
> > As I said though, I just don't know that code well
> > enough to propose a fix.
>
> ENOTSUP seems to be the most "correct", although I sort of
> see it being the equivelant of dis
* Tim Kientzle <[EMAIL PROTECTED]> [070617 21:52] wrote:
>
> 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:
> * lsee
On Monday 18 June 2007 15:36, Andrey Chernov wrote:
> Then it should be fixed in the driver, please do not mask this bug in
> the bsdtar workaround. Ask adaptec driver people for help.
I think that masking the bug AND asking for help is the right thing to
do.
It's silly to think that we need a s
On Sun, Jun 17, 2007 at 09:52:10PM -0700, Tim Kientzle wrote:
> 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
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. :
Tim Kientzle wrote:
> I fear I'll have to
> avoid seeks under other circumstances. (For instance, tape drives on
> FreeBSD seem to return garbage from lseek().)
Is there any reason why the tape drivers can't be fixed? The idea of
putting workarounds into bsdtar for a problem which could eq
kientzle2007-06-18 00:36:54 UTC
FreeBSD src repository
Modified files:
lib/libarchive archive_read_open_fd.c
archive_read_open_filename.c
Log:
Track whether the current read stream supports seek(). For now, we
assume yes unless seek has previous
10 matches
Mail list logo
