Re: Tshark closing unexpectedly due to failure reading from file

[Guy Harris <gharris () sonic net>]

On Nov 18, 2020, at 4:25 PM, James Ko <jck () exegin com> wrote:

> I've been helping Alastair debug this problem and this is as far as we got.
> I can only think of a race condition between dumpcap completing the packet writing to the file and tshark being able 
> to read the expected number of new packets.
>
> I do see there is fflush() in capture_loop_write_pcapng_cb() before the capture_loop_wrote_one_packet() which 
> actually increments the number of available packets.
>
> Do we also need an fsync() here to ensure the data is written to the disk?

If this is on UN*X, that would be an issue only if your UN*X is really stupid about managing the buffer/page cache.  I 
know of no UN*Xes where that's the case.

If this is on Windows, I *still* wouldn't expect it to be the case, at least on any Windows NT-based version (and we 
haven't supported Windos 95/98/Me for a long while, and neither has Microsoft...), as I think it has the same sort of 
buffer/page cache as most if not all UN*Xes these days have.

I.e., if process A is writing to a file, and process B is reading from a file, process B's write should immediately 
update the buffer/page cache, so process B's read should see it, as long as the read is done after the write.

flush() just means "do a write to the underlying file immediately"; it doesn't imply anything more than write() on UN*X 
or _write() on Windows (which, in turn, turns into a WriteFile() if you're writing in binary mode), so it updates the 
buffer cache but doesn't necessarily update the file on secondary storage.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe