Wireshark-bugs: [Wireshark-bugs] [Bug 4811] popup error window won't go away when underlying tra
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4811
--- Comment #3 from Guy Harris <guy@xxxxxxxxxxxx> 2010-10-18 16:46:43 PDT ---
What does "touched" in "being touched while on an SMB share" mean here?
"Written to"?
I could reproduce a similar problem on Mac OS X (and probably thus on every
other UN*X) by making a copy of a capture file I had handy, opening it up,
truncating it to zero length (with "> {file name}" from a Bourne-compatible
shell), and clicking on a whole bunch of packets; it took several clicks before
the dialog box popped up (probably because the first few packets were in the
4KB or so stdio buffer, and no read() calls had to be made to the file), but
eventually it did. I could dismiss the dialog box, however.
I tried it again, and I got a crash:
16:38:45 Err file new_packet_list.c: line 1313 (show_cell_data_func):
assertion failed: (cell_text)
Abort
which Kevin wouldn't have gotten (1.2.x doesn't have the new packet list code).
I think the difference there might have been that I scrolled the window, so
the new packet list code had to read the packet, and it might not be prepared
for the read to fail at that point.
There are a couple of issues here:
1) Windows allows an open to be "deny write", which will prevent other
processes (on the same machine, or on other machines accessing the file using a
protocol that supports deny modes, e.g. SMB and, at least if all the clients
are cooperating, NFSv4) from opening the file for writing. Were we to do that,
it might prevent at least some problems of this sort, although if what we have
open is a file for a live capture, we obviously can't deny writing in
Wireshark, because as new packets arrive dumpcap has to write them to the file.
It also won't prevent the problem on most UN*X systems, as they lack enforced
deny modes (BSD-flavored systems, including OS X, have O_SHLOCK and O_EXLOCK,
but those only lock out other programs using those modes, they don't lock out
somebody opening the file with neither of those modes, and most programs don't
use those modes).
2) Once we get the "less data is available than was written" error, we
might want to forcibly close the capture file, as it might have been modified
out from under us.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
