@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 <ghar...@sonic.net> wrote: > On Nov 18, 2020, at 4:25 PM, James Ko <j...@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-requ...@wireshark.org > ?subject=unsubscribe
___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe
