[robert.bullen@xxxxxxxxxx]

> Nothing currently uses them - the progress bar for
writing out a capture file counts packets, not bytes, and making it count
bytes would require a pass through the capture to ask Wiretap how many
bytes each packet would require before writing the file out - and writing
out a capture file doesn't necessarily proceed 100% sequentially in any
case.

> Is there any use for those routines, or the bytes-dumped count they
fetch and set?

Guy, I have some code that takes advantage of wtap_get_bytes_dumped().
It is an enhancement to editcap that allows the user to specify an approximate
upper limit on the size of output file segments (akin to the -i or -c switches,
except specifying KBs rather than seconds or frame counts).

Implementing this feature required that I make a pass
through many of the file formats to insert code that correctly increments
the bytes dumped counter as blocks of data are written to the file. And
while it is true that some file formats do not write contents to the file
sequentially, all the ones that I looked at (all that support Ethernet
encapsulation) advance the file size linearly from start to finish, but
may go back and fill in areas that were skipped over. For example, some
file formats don't write the file header until finalizing the file, when
things like frame counts are known. But the file header must be skipped
over during initialization, so the bytes dumped counter is incremented
then, rather than when the header is actually filled in with valid data.

So the value returned by wtap_get_bytes_dumped() as
I implemented it can be thought of as a file size high water mark, and
is accurate up to the last write operation. My editcap algorithm would
determine if the next packet to be written (and only the packet, not any
accompanying header/metadata/what have you, would exceed the user-specified
upper bound, and if so start a new file. The resulting file may exceed
the upper bound by a maximum of a single frame header plus a file footer
(if the format requires it). But that's OK if you can accept that the user
is specifying an approximation.

But you are right; if we want complete accuracy when
writing then another function is necessary to ask Wiretap, "how many
bytes are you about to write for this operation", where operation
could be opening the file, writing a packet, or closing the file.

I did not use the wtap_set_bytes_dumped() function
for any of this, instead electing to increment the wtap_dump->bytes_dumped
field directly. I personally feel that wtap_set_bytes_dumped() should not
exist, or if it does it should not be exported outside of the Wiretap library
as it allows clients to muck with internal state.

Robert Bullen

U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.


---------------------------------------------------------------------