[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

Have you been able to replicate the issue on another system to rule out a local environmental problem?

On Thu, 19 Nov 2020 at 08:37, James Ko <jck@xxxxxxxxxx> wrote:

@Guy.  This is on ubuntu linux distribution.  I'm using Xubuntu 18.04LTS and I believe Alastair is on Ubuntu 16.04LTS.

Assuming the buffer/page/disk cache is not doing the right thing is there anything we can try to make sure it's consistent?

@Jaap.  We will be sure to update to the latest release but I don't expect this will make much difference as the dumpcap/tshark interface has been around for years.

James

On Wed, Nov 18, 2020 at 9:22 PM Guy Harris <gharris@xxxxxxxxx> wrote:

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.      mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

--

Graham Bloice