packet_range_init(). Get rid of global cfile references in
packet-range.c. C++-ize packet-range.h. Shuffle some includes around.
svn path=/trunk/; revision=45333
cf_read() is already checking for cf->redissecting variable and if set it don't add packets to packet_list.
Rename it to cf->rescanning and set it always in rescan_packets() [not only when redissecting].
svn path=/trunk/; revision=45183
When refiltering we process gtk/glib events, so it's possible that cf_continue_tail()
will fire-up, reading new packets and incrementing cf->count.
It's also possible that this packet(s) will pass display filter,
incrementing cf->displayed_count.
But when refiltering we use cf->count as number of packets to process, so
new packets are also processed, incrementing cf->displayed_count second time.
Fix bug by saving cf->count before starting refilter loop.
svn path=/trunk/; revision=45182
fileset_file_opened directly from file.c. This makes the code a bit more
consistenent and makes it easier to port the File Set dialog to Qt.
svn path=/trunk/; revision=45162
This commit reduces size (from 144B to 128B on AMD64) of frame_data structure.
Part of bug 5821: Reduce per-packet memory requirements.
svn path=/trunk/; revision=45071
Use and free err_info in cf_continue_tail() and cf_finish_tail().
(Untested because I'm not sure how to corrupt a file to exercise this code path...)
svn path=/trunk/; revision=45032
the per-file encapsulation type needed to write out a set of packets
with all those encapsulation types. If there's only one such
encapsulation type, that's the type, otherwise WTAP_ENCAP_PER_PACKET is
needed. Use that in wtap_dump_can_write_encaps().
Also use it in cf_save_packets() and cf_export_specified_packets(), so
that we can write out files with WTAP_ENCAP_PER_PACKET as the file
encapsulation type and only one actual per-packet encapsulation type in
some cases where that failed before. This fixes the case that showed up
in bug 7505, although there are other cases where we *could* write out a
capture in a given file format but won't be able to do so; fixing those
will take more work.
#BACKPORT
(Note: this adds a routine to libwiretap, so, when backported, the
*minor* version of the library should be increased. Code that worked
with the version of the library prior to this change will continue to
work, so there's no need to change the *major* version of the library.)
svn path=/trunk/; revision=43847
so that we can properly associate a widget with create, update, and
destroy events. Only used by Qt so far but it should be easy enough to
add to GTK+.
Rename ui/qt/progress_dialog.{h,cpp} to progress_bar.{h,cpp}. Show a
progress bar in the status bar of the main window instead of creating
a separate dialog. Note that we still need to add a "cancel" mechanism
and display the task and item titles somewhere.
Thus began the War Against Gratuitous Dialogs.
svn path=/trunk/; revision=43833
the file has unsaved changes, and we can save it in some format
through Wiretap
or
the file is a temporary file and has no unsaved changes (so that
"saving" it just means copying it).
Only allow "Save As" if
we can save it in some format through Wiretap
or
the file is a temporary file and has no unsaved changes (so that
"saving" it just means copying it).
This means that we don't support using "Save As" for just copying the
file unless we can do that with Wiretap; copying the file byte-for-byte
only works as "saving" if there are no unsaved changes *and* we're
saving it in the same format that it's in *and* we're saving it with the
same form of compression (if any) that it has.
Rename cf_can_save_as() to cf_can_write_with_wiretap() to better reflect
what it really does.
svn path=/trunk/; revision=43477
in a format that supports comments and they do a "Save" by popping up a
similar question to the one we pop up in the "Save As" case and, if they
say "choose another format", pop up a "Save As" dialog box.
svn path=/trunk/; revision=43395
tries to do "Save As" in a format for which we don't support comments
(currently, we only support them for pcap-ng), ask whether they want to
discard the comments and save anyway or, *if* the file can be saved in a
format for which we *do* support comments, they want to save the file in
some other format.
Keep a count of packet comments so that we don't have to scan all the
frame_data structures to determine whether we have any comments.
svn path=/trunk/; revision=43392
file.c and routines called from it; non-modal dialogs end up, in some
cases, either hidden, devoid of the input focus and not dismissable, or
both.
svn path=/trunk/; revision=43321
file type and a GArray of encapsulation types and returns TRUE if a
capture with all those encapsulation types can be written to a file in
that file type and FALSE otherwise. Use it where appropriate.
svn path=/trunk/; revision=43315
Show all of them in the summary dialog; we will be using it in the
future to figure out what capture file formats we can write to (just
because a capture file format supports per-packet encapsulations, that
doesn't mean that it supports *all possible* encapsulations).
svn path=/trunk/; revision=43278
When building current data for packet details treeview we store two things.
- Generated string with item label
- Pointer to node field_info structure
After epan_dissect_{free, cleanup} pointer to field_info node is no longer
valid so we should clear GtkTreeStore before freeing.
svn path=/trunk/; revision=43188
just tweak the elements in the capture_file structure as necessary and
poke the UI to update stuff such as the windows title.
If we do a Save or Save As with a copy, don't reread the capture file,
just close the old wtap, open a wtap for the copy, and tweak the
elements in the capture_file structure as necessary and poke the UI to
update stuff such as the windows title.
Otherwise, don't do a full read-and-dissect pass on the capture file,
just close the old wtap, open a wtap for the new file, tweak the
elements in the capture_file structure as necessary and poke the UI to
update stuff such as the windows title, and rescan the file to update
the packet offsets (and cause Wiretap to regenerate, for a gzipped file,
the information needed to support fast random access to the gzipped
file).
This should speed up Save and Save As a bit, as well as removing some
glitches in the UI (e.g., you won't see the packet list disappear and
reappear).
svn path=/trunk/; revision=43101
"export specified packets". For "failed", let the user try again with a
different file, in case it failed due to, for example, running out of
space or quota (probably the most likely failure mode for writing, and
trying to a different volume might be the best workaround). For "user
stopped it", presumably they don't want to try again (the most likely
reason is "it was taking too damn long").
Put "Exporting to: ...", not "Saving: ..." in the statusbar if we're
doing "export specified packets".
In process_specified_packets(), allow a null range pointer to be
specified, meaning "save 'em all"; that avoids the possibly-expensive
(with a large capture) operation of initializing the range.
If a "safe save" atop an existing file fails or is stopped, get rid of
the temporary file we created.
svn path=/trunk/; revision=43095
update it after each burst of packets. (This is broken - we should have
cf->lnk_t be WTAP_ENCAP_PER_PACKET in all capture file formats that can
handle more than one packet type, and, in order to support writing out
*some* such files in formats that can only handle one packet type, just
use the type of the first packet when doing a one-pass operation and
gather up all the packet types in a multi-pass operation.)
svn path=/trunk/; revision=43048
callers either need to free it or their callers need to free it or....
This means that cf_get_display_name() must always return a g_mallocated
string and its callers or... must free it.
For some of those callers, create a new set_window_title() routine to do
the work - they're all using the same pattern.
svn path=/trunk/; revision=43047
getting the basename for display purposes, so it's converted from the
GLib/GTK+ locale filename encoding to UTF-8. (For Windows, the locale
filename encoding is UTF-8, and the internal encoding is UTF-16, so the
file names should *probably* all be valid UTF-8 - Windows may not
support invalid UTF-16 in file names. For Qt, I'm not sure whether the
file dialogs ever return file names in some non-UTF-8 encoding.)
svn path=/trunk/; revision=43044
doesn't do safe saves, so wtap_fdreopen() always needs to reopen the
random file descriptor.
At the point where a safe save is done, the sequential read is done, so
the sequential stream is closed; there's no need to reopen it.
(The former fourth argument to wtap_fdreopen() wasn't an indication of
whether the file was compressed, it was an indicationof whether the
random stream should be reopened.)
svn path=/trunk/; revision=42977
file that we ourselves have open. In the "safe save" code path for
capture files, on Windows temporarily close the file descriptors for the
currently-open capture before doing the rename and then, if the rename
failed, reopen them, leaving the rest of the wtap and capture_file
structures intact.
Rename filed_open() to file_fdopen(), to make its name match what it
does a bit better (it's an fdopen()-style routine, i.e. do the
equivalent of an open with an already-open file descriptor rather than a
pathname, in the file_wrappers.c set of routines).
Remove the file_ routines from the .def file for Wiretap - they should
only be called by code inside Wiretap.
Closing a descriptor open for input has no reason to fail (closing a
descriptor open for *writing* could fail if the file is on a server and
dirty pages are pushed asynchronously to the server and synchronously on
a close), so just have file_close() return void.
svn path=/trunk/; revision=42961
temporary file to which we were writing in order to do a "safe save".
Thanks to Coverity for pointing this out - should fix CIDs 703317 and
703316.
svn path=/trunk/; revision=42891
have the file open. Go back to doing it with a copy on Windows.
Explain what the problem is, and give a way in which we might be able to
make it work on Windows (without using any NT native API calls...).
svn path=/trunk/; revision=42859
saving files, and run it modal (which we're already doing with the
GtkFileChooserDialog); this means less callback-based state machine
stuff, simplifying the code paths a bit.
If we're saving a file before closing it, don't bother reloading it
after saving it.
svn path=/trunk/; revision=42855
an API to fetch that.
When doing "Save" on a compressed file, write it out compressed.
In the Statistics -> Summary dialog and in capinfos, report whether the
file is gzip-compressed.
svn path=/trunk/; revision=42818
save" if the destination file exists.
Don't forbid overwriting an existing file in either of those cases (we
still forbid overwriting the current capture file) - the GUI asks the
user whether they want to do the overwrite, and allows them to cancel
out of it - and don't remove the file before writing to it (doing so
makes the save *un*safe).
Attempt to do a save of an unedited temporary file by just moving the
file on Windows as well as on UN*X - ws_rename() will remove the target
if necessary on Windows (and won't do it as a separate operation before
attempting the rename), so it behaves like ws_rename() on UN*X (which is
just a wrapper around rename()).
svn path=/trunk/; revision=42816
new file the current file, as is the case in most if not all other GUI
applications.
A new "Export Specified Packets" menu option allows you to specify which
packets to write out, with the default being the displayed packets (and
those on which the displayed packets depend for, e.g. reassembly), and
never makes the resulting file the current file.
The two operations are conceptually distinct. Lumping them into one
menu item, with the default for "Save As" being "displayed packets only"
and thus making it behave like the latter operation, was causing some
confusion; see, for example, bug 6640.
Make the dialog popped up if you try to "Save As" or "Export Specified
Packets" on top of an existing file ask the "do you want to do this?"
question in the main part of the message, and note in the secondary text
that doing that will overwrite what's in the file; that matches what
TextEdit on OS X and the GNOME text editor say.
svn path=/trunk/; revision=42792
so "Save" should, for non-temporary files, mean "save the current state
of the capture file on top of the existing file" without prompting for a
file name.
That means we have to do a "safe save" - i.e, write the capture out to a
new file and, if that succeeds, rename the new file on top of the old
file - as the actual packet data to write out is in the file we're
overwriting, not in memory. (We'd want to do that anyway, of
course....)
Update some comments.
Clean up indentation slightly, and get rid of an unnecessary variable
(in all the cases where we use it, we assign it the same value, and that
value isn't modified out from under us before we use it).
Note that after a "Save", or a "Save As" that writes out all captured
packets, we shouldn't have to close the current file and open the new
file and reread it - we should be able to open the new file and update
the frame offsets in the frame_data structures.
Note that we need to do some a better job of reporting rename failures.
svn path=/trunk/; revision=42777
save, we post capture file callback events similar to the ones posted
when reading a capture - otherwise, the reload will leave the welcome
screen up.
Rename cf_cb_file_save_reload_finished to cf_cb_file_reload_finished,
add a cf_cb_file_reload_started callback, have them work similarly to
read_finished and read_started except that the reload uses "Reloading"
in the progress bar and status bar.
Clean up some indentation while we're at it.
svn path=/trunk/; revision=42764
Revert r42758 as it only helps in one case; rather, fix it correctly: if
we're redissecting or refiltering, clear any frame dependencies as we go
along. (Fortunately, frame dependencies are all forward dependencies--
meaning that a given frame can only be depended upon by a later frame--
so we can do this as we rescan the packets/frames.)
svn path=/trunk/; revision=42762
Clear the dependent_of_displayed flag when there's no dfilter. This only
helps the case when you clear a display filter before moving on to another
display filter.
svn path=/trunk/; revision=42758
Don't mark frames as dependent upon a displayed frame unless the (supposedly)
displayed frame is actually displayed. (Fix to r41214 <sigh>.)
svn path=/trunk/; revision=42752
Gerald Combs