gcla/termshark

Pcap is saved to cache silently without user input

Closed this issue · 7 comments

pocc commented

Screen Shot 2020-03-29 at 9 49 26 PM

These are all pcap files

Why is the cache so large? Is it possible to create a configuration default for cache size to avoid this scenario? In my opinion, termshark should not have a cache larger than 1GB.

I have not tested whether this applies to other OSes as well, but I would assume that you haven't made any macos-specific cache code.

former title: Cache is ~40GB on Macos

gcla commented

hi @pocc - you are right, no cache maintenance at all, and agreed, there should be a way to set a limit. I'll have a shot at it when work-work quietens down and let you know

gcla commented

Hi @pocc - if you have the time, could you try a build from the prunecache branch? Here's a link to the commit with the details: 47d705f

gcla commented

I'll merge this and close the PR. Please re-open if it's not up to par :-)

pocc commented

Sorry to take so long to respond on this. I took a look at the commit and I think this creates an option to preempt the issue (I.e. progress), but doesn't address it. Of thousands of users, only a handful will even be aware of this option (a greater number will be aware that termshark is even configurable).

In my opinion, taking up ~40GB of hidden cache without notifying the user is a catastrophic failure in error messaging. Tshark and tcpdump get around this by requiring the user to explicitly save their files or output to stdout (wireshark creates one temporary file while capturing, but the user is prompted to do something with it before quitting).

Question: Why are pcaps saved at all after capture? Do people actually use the cache to look at past captures (and do you)? Alternatively, why not imitate Wireshark's ask-to-save-on-quit/ask-to-save-on-new-capture dialog?

gcla commented

No problem, didn't mean to rush you :)

I don't have much data on what people use, honestly. I suppose it would come via github (there's no telemetry of course). I do use the cache in the sense that I often invoke termshark like termshark -i eth0 but absent asking for further input, I decided it's wrong to throw away the packets on exit. You're right that it could require further input and prompt the user instead, like Wireshark. Maybe I could add a '-w' flag like tshark; then without the '-w' flag, termshark should prompt 'save yes/no', with the default location being the cache..?

I am working, slowly, on a simple preferences dialog to make these options more discoverable, and this cache size will be one of them. Do you think that would help? Maybe I should add a one-time "hey look there is a new cache size option" window too...

pocc commented

No you're fine. 2 weeks is a long time, but seems to pass quickly in quarantine-time :-).

I don't have much data on what people use, honestly.
This sounds like a good reason to add telemetry. If you don't interact with your users outside of issues, how do you know how they use the program?

I think you should aim to imitate the Wireshark/tshark UI wherever possible, as that is what people will expect. Wireshark when in the TUI; tshark while calling it on the CLI.

Maybe I could add a '-w' flag like tshark; then without the '-w' flag, termshark should prompt 'save yes/no', with the default location being the cache..?

Using -w sounds like a good idea. I would avoid saving to the cache unless the user has explicitly set the cache as the destination. The default should be the current directory, as that is where most users will expect output to go (if output is not sent to stdout).

I am working, slowly, on a simple preferences dialog to make these options more discoverable

I think it is a good thing to make these options discoverable. For this specific option, I'm questioning the wisdom of having a pcap cache at all (maybe ask a user or two whether they use it?), regardless of whether it can be controlled through preferences.

gcla commented

I'll close this in favor of #111.