On Nov 18, 2020, at 4:25 PM, James Ko <jck@xxxxxxxxxx> 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.
