> I'm very unhappy about having two separate handles to the file - one
> for reading the data through file(d)_open and another through
> fopen.
(Presumably you mean "and another through 'open()'", not "through
'fopen()'".)
The first handle is derived from the second, so they7're not really
separate handles. We've always two separate handles, in effect - given
that "fileno()" exists, you can always get at the underlying file
descriptor for a "FILE *". Stuffing a file descriptor into the "wtap"
structure is just a workaround for the fact that "-lzlib" doesn't let
you get at the underlying file descriptor.
> Given that starting capture is done through a CLI command
> (presumably), the exact time of this is not that useful, IMHO. This is
> the only thing we gain.
Nope.
We also gain the ability to find out how much of the file we've read, by
seeing what the current seek offset in the file is, and how large the
file is; the progress bar doesn't necessarily move at the correct rate
if you're reading a compressed file, as it shows how far you are into
the compressed file rather than how far you are into the uncompressed
file, but it's better than nothing; given that we haven't yet gotten
file reading to run so fast that progress bars are irrelevant, I'm not
happy about the progress bar being replaced by a bounce bar, as the
latter doesn't tell me even approximately how soon it'll be done.
Hopefully, with only 100 total updates to the progress bar, the
"fstat()" calls needed to measure progress won't slow things down too
much.
> Incidentally, the progress bar doesn't move with Ascend captures
> - though I don't believe this has changed.
It has changed. It moved with the code before your checkin - which
isn't surprising, as Wiretap doesn't move it, Ethereal moves it, and
Ethereal doesn't care what type of capture file it's reading when it
updates the progress bar. (After your change, there isn't a progress
bar....)
