Feature request: never delete log data in any case (not just the ↻ Reset button), and support for reading across archived logs as one continuous history

[Frankthetankk]

I'd like to request that EQBuddy never delete my log data under any circumstances — not the 60+ minute auto-cleanup, not the ↻ Reset button, not any other process. This isn't about one specific accidental click; it's a general request to remove deletion as a possibility entirely, in favor of archiving.

To be clear on the underlying concern: I don't mind EverQuest's own log file growing without bound. If it ever gets too large for my taste, I'm fine manually emptying it myself, on my own schedule, when I choose to. What I don't want is EQBuddy (or any button/automatic process within it) ever doing that deletion on my behalf, especially silently or by accident.

Related issue with the ↻ Reset button specifically: its tooltip reads "Reset session stats," which reads like it only clears displayed numbers — but per the README, it actually archives-then-empties the underlying log file. That wording mismatch is part of the problem; a button described as resetting "stats" doesn't read as something that also modifies your actual log on disk. A few smaller asks around this one:

1. A confirmation dialog before Reset runs — even a simple "This will archive your current session and start a new log. Continue?" would help.
2. Clearer button/tooltip wording that reflects what it actually does to the log file, not just the displayed stats.
3. Some way to verify from within EQBuddy that "Keep a timestamped copy before emptying" is actually working — e.g. a confirmation toast/notification when a session is successfully archived, with the file path, so the archive isn't something the user just has to trust blindly.

Bigger ask, and the one I care about most: a setting to disable log deletion entirely, everywhere in the app — archive as often as you like, but never actually empty/delete anything, whether that's the 60-minute idle cleanup, the Reset button, or anywhere else.

Related idea that would make manual deletion safe too: when I do decide to empty my live EQL log myself (for file-size/performance reasons, not because I want to lose history), it would be great if EQBuddy could read across all my archived logs AND the current live log as one continuous timeline — oldest archived timestamp through to the most recent live entry, no overlap or duplicated data — so all-time stats, history, and calculations still work exactly as if it were one single unbroken log file. That way emptying the live log on my own terms would only ever shrink the file on disk, never cost me any actual history or break EQBuddy's ability to calculate across my full play history.

A few things I'm sure would need thought on the implementation side, flagged in case they're useful:

• Performance: scanning every archived file to compute all-time stats could get slow for someone with a long history. This might make more sense as an on-demand "rebuild all-time history" action rather than something recalculated live every session — whatever's easiest to implement well is fine by me.
• Session boundaries across archive+live: would want the existing "60+ min idle = new session" logic to still work correctly when spanning archived and live files, so sessions don't get miscounted or merged incorrectly at the seams between files.
• Storage growth: if nothing is ever deleted, archive files will accumulate indefinitely for anyone with a long play history. I'm personally fine with that tradeoff (same as I'm fine with EQL's own log growing unbounded), just flagging it explicitly so it's a known, accepted consequence rather than an oversight.

Separately — not really part of this feature request, but a fair question while I'm here: is there any existing way to recover a session that got emptied without an archive copy already in place? I got lucky this time (had separately uploaded my log elsewhere before the reset happened, so I could stitch it back together), but I'm curious if there's an official recovery path for anyone else who hits this before these changes ship.

This came up because I had a session get emptied (auto-cleanup after 60+ min idle) and had a scary moment not knowing whether the data was actually recoverable. I was able to recover it a different way this time, but it made me realize how little visibility/confirmation there currently is around the archive actually working, and how much I'd prefer deletion never be possible in the first place.

[DranakCorps-bot]

This is a really good report — and the timing is almost unfair, because a chunk of what you're asking for shipped in v1.84.0 a couple of hours before you posted it. Let me go through it honestly, including where I disagree.

First: I'm sorry you had that scare

Losing a session and not knowing whether it was recoverable is exactly the experience EQBuddy shouldn't be creating. That it took a data loss to expose how little visibility there was around archiving is on me, not on you.

What's already true as of v1.84.0

Archiving is on by default now, for existing installs too (that was wizen's #146). Every finished session is copied to Logs\archive before the idle cleanup empties anything. So the specific way you lost data — 60+ minute cleanup with no copy — can't happen on 1.84.0 unless someone deliberately turns archiving off.

And "never empty anything" is already available: ⚙ Options → untick "Clean up finished session logs". That disables the idle cleanup entirely. Leave archiving ticked as well and you have belt and braces.

What I'm changing because of your report

1. The ↻ button was lying by omission, and you're right about it. Its tooltip said "Reset session stats". It now says what it actually does, built from your current setting:

Start a new session — Stats reset to zero, and your current log moves to Logs\archive so a fresh one can begin. Nothing is deleted.

2. It asks first. Same treatment Epic Complete got after #138 — a confirmation naming the file operation before it happens. With archiving off there's no dialog, because in that mode Reset genuinely doesn't touch your log and a pointless dialog just teaches people to click through dialogs.

3. Every archive announces itself, with the path. Your third ask, and the one I think was sharpest. A banner when it happens, and a line in error.log — because the banner answers "is this working right now" and the log answers "did it archive that session last Tuesday". The janitor runs unattended on a background thread; an archive nobody is told about is indistinguishable from one that never happened.

Where I'd push back

Reset was never deleting anything. With archiving on it moves your log into Logs\archive and starts a fresh one — a rename, not a delete. With archiving off it doesn't touch the log at all. The README's "archives-then-empties" wording made it sound worse than it is, and I'll fix that too. Your underlying point stands completely — the button did more to your disk than its label admitted — but I don't want you thinking data went into a shredder.

I'd rather not add "never delete, anywhere" as a separate master switch. Between the cleanup toggle and the archive toggle the capability already exists, and a third setting that overlaps two others tends to create the question "which one actually won?" — exactly the kind of ambiguity that got us here. If you find the current two hard to reason about, tell me and I'll revisit; that's a real argument, I just don't think a third switch is the answer to it.

The big one: reading across archives as one continuous history

I want this, David wants this, and it isn't happening this week — it's a proper feature, not a tweak. Your three flagged concerns are the right three, and they're the reason:

• Performance — you're right that it wants to be an on-demand "rebuild all-time history" action rather than something recomputed every launch.
• Session boundaries at the seams — the 60-minute rule has to keep working across file boundaries, or sessions get merged or split at the joins. This is the actually-hard part.
• Storage growth — noted and accepted, and thank you for saying so explicitly rather than leaving it as a surprise.

I'd add a fourth: overlap. Archives can contain lines the live log still holds, so it needs to de-duplicate by timestamp+content rather than trust that files don't overlap.

It's on the list as a designed feature. I'd rather tell you "not yet, and here's what makes it hard" than promise a date I'd miss.

Your last question — recovering an already-emptied session

Honestly: if there's no archive copy and no external backup, EQBuddy can't get it back. It only ever reads the log; it keeps no shadow copy of raw lines. Session summaries survive in Session History (⚙ → History) because those are written to EQBuddy's own database as the session runs — so totals, kills and loot for a lost session are usually still there even when the raw log isn't. That's not the same as having the log, but it's often more than people expect. Anyone in this position before upgrading: check History before assuming it's all gone.

You did the right thing having it uploaded elsewhere. As of 1.84.0 that shouldn't be necessary.

Thanks for writing this up at length — the tooltip point in particular is one I'd have kept walking past.

[Frankthetankk]

Appreciate the thorough writeup — and yes, the timing worked out well on your end.

On the master switch: I'm satisfied with the two-toggle approach as-is. Your reasoning about ambiguity ("which one actually won?") makes sense, and honestly the real problem in my original report wasn't that a "never delete" switch didn't exist — it was that I had no visibility into whether archiving was actually working. The banner + error.log fix addresses that directly, which was the sharper issue. No need to add a third switch on my account.

Reset button wording/confirmation and the archive verification — all good, matches what I was hoping for.

Leaving this open rather than closing it, since the continuous-history piece is still the part I care about most and it's still just on the roadmap. Happy to help think through the four flagged concerns (performance, boundaries, storage, overlap/dedup) whenever it's actually being scoped — no rush, just wanted to flag I'm still interested whenever it gets picked up.

Thanks again for the fast turnaround and for taking the tooltip complaint seriously — that's exactly the kind of small-but-real fix that's easy to deprioritize.

[DranakCorps-bot]

Good — the two-toggle answer standing, and the visibility fix being the real repair, matches how we saw it land too.

On the piece you're leaving the thread open for: continuous history across archived logs is still the direction, and it hasn't moved yet. The archives are already accumulating on disk with nothing lost, which was the prerequisite — what doesn't exist is the query layer that reads across them as one history. When it starts, this thread is where progress gets reported. No date attached, because a date without work behind it would be the kind of promise this project tries not to make.

— Dranak (Claude Code)