only if the capture file format is PCAPNG). This can happen if the user
does not have a PCAPNG file but has added a capture-file comment via the
add/edit capture file comment UI.
Replace some tabs with spaces and wrap a few long lines.
svn path=/trunk/; revision=42827
source isn't compressed and the target is (or vice versa), enable the
"compressed" checkbox in the Save As and Export Specified Packets
dialog. Fix it to clear the checkbox if the selected file format
doesn't support gzipping.
svn path=/trunk/; revision=42822
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
the default extension for the file type iff
the file type we're using has a list of extensions;
the file has no extension or it has one but it's not one of the
ones in the list.
*Don't* expect a file extension to be at most 5 characters plus the dot
- the extension for pcap-ng, our default capture file type, is "pcapng",
and that's 6 characters!
svn path=/trunk/; revision=42800
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
File -> Export Packet Dissections
(for the "print to file", "export as CSV", "export as C array",
"export as PSML", and "export as PDML" items)
File-> Export Selected Packet Bytes
File -> Export SSL Session Keys
File -> Export Objects
(for exporting objects transferred over HTTP, DICOM, or SMB)
menu items.
The operations under Export really weren't that related - about all they
had in common was that they wrote to a file stuff other than packets
in a capture file format; the operations in the groups *under* Export
were related, so the groups are now menu items of their own.
This way, the File menu more immediately indicates what options of that
sort are available.
It also means that the Export Packet Dissections item might make it
clearer that what you get from that is *NOT* something that can just be
read back into Wireshark, as at least one user who asked "how do I get
my capture back from this?" on ask.wireshark.com thought. If that
doesn't suffice, perhaps renaming it to "Export Dissected Packets" would
help; if *that* doesn't suffice, perhaps Kevin Cullimore's suggestion
that it say "Report" rather than "Export" will do the trick:
From: Kevin Cullimore <kcullimo@runbox.com>
Subject: [Wireshark-users] Re: Should the "export as text" item be in an "Export Human-readable..." item in the File menu?
Date: May 19, 2012 8:31:23 PM PDT
To: wireshark-users <wireshark-users@wireshark.org>
Would classifying the asymmetric export (ones that lack a
corresponding "import" action) formats as "reports" help clear
up the original ambiguity/misunderstanding? It seems that most
of the gui-based network tools I'm forced to periodically
interact with rely upon that term with at least some success.
(Or perhaps some other verb would be right in some cases, e.g. "Save SSL
Session Keys".)
This also sets a pattern for another upcoming change - splitting "Save
As" into "Save As", which always saves every packet and makes the new
file the current file, and "{Verb} Specified Packets", which lets you
specify which packets to save and does *not* make the new file the
current file. That'd simplify the code a bit, and might clear up the
new only-in-the-trunk issue in bug 6640 - having "Save As" default to
saving displayed packets currently means that it acts more like the
latter of those functions.
svn path=/trunk/; revision=42778
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
"unsaved_changes", and have it be TRUE iff changes have been made to the
file since it was read - *not* if it's a temporary file from a live
capture.
Check the "is_tempfile" member, and the "unsaved_changes" member, when
appropriate.
Just have a set_toolbar_for_capture_file() routine that updates the
"save", "close", and "reload" toolbar as appropriate, given a
capture_file structure - absorb the function of
set_toolbar_for_unsaved_capture_file() into it.
svn path=/trunk/; revision=42721
We're already checking in gtk if end highlight offsets don't exceed len.
Do the same for start offset.
I wonder if it this checks should be also done when adding items to tree...
svn path=/trunk/; revision=42596
Sort the recent filters list by "most recently used" (that is, put the most
recently used filter at the head of the list).
svn path=/trunk/; revision=42439
Get rid of gtk_widget_set_size_request() calls - at least on my machine
and GTK+ version, they make some of the items too small to show the full
text. Let GTK+ figure out how big things have to be - and if that makes
the toolbar too wide, redesign the toolbar.
svn path=/trunk/; revision=42277
Separate "Toolbar" from the toolbar name in the View menu items.
Use "l", rather than "W", as the whatchamacallit for the wireless
toolbar - "W" is already used for "show packet in new window".
svn path=/trunk/; revision=42275
