> Yes, but you can't use this offset for determining how far you are in
> the file, because you don't know the length of the uncompressed
> data. You have to do a lseek(fd, 0, SEEK_CUR) to determine the actual
> file position of the file. And that seems to jump straight to 20K.
But were we not talking about the case *before* uncompression was added?
You said
I don't see how it could have worked
in response to
It has changed. It moved with the code before your checkin
(i.e., before Wiretap was changed to use zlib); as such, you *do* know
the length of the file, because you did an "fstat()" on the file, and,
before Wiretap was changed to use zlib, *all* files were uncompressed.
> > Note also that the parser, and thus the lexical analyzer, are called
> > once for every packet, with the file position set before it's called -
> > see "ascend_read()".
>
> Yeah, but lex appears to be buffering internally.
Lex shouldn't be buffering stuff between packets; if it is, that's a
problem, given that we may have moved the seek pointer.
It may be reading more than just the data that constitutes the packet,
but, for a file large enough that the progress bar doesn't just go "zip"
across the widget, is it buffering enough that if we call "lseek()" on
the file descriptor (or call a Wiretap routine to do so for us, so that
we don't have to get at said descriptor ourselves) if we're supposed to
update the progress bar on this call, the value it gets will be so far
off that the progress bar won't work well?
