Sumatrapdf: SessionData gets deleted when opening new tab

[bradrn]

In SumatraPDF, I have enabled the ‘Remember opened files’ setting. This usually works fine: I can close SumatraPDF and then reopen it, and all my previously opened files will still be there. As far as I can tell, this works by saving the list of opened files in the SessionData field in the SumatraPDF settings file (SumatraPDF-settings.txt on my computer), and then reading this field when SumatraPDF is opened again.

However, this functionality seems to have a bug: when I open a new file, the SessionData gets deleted. Now, normally, this would not be a problem — I can simply close SumatraPDF normally to re-write the list of opened files to SessionData. However, if my computer crashes (which it seems to do with depressing regularity), or if SumatraPDF crashes (which thankfully is far less common), then the SessionData stays blank and I lose all my opened files. This is _incredibly_ frustrating when it happens, as I will often have 10 or more files open at a time in SumatraPDF. Curiously, this does not happen when I close a tab — when I do that, the SessionData simply stays the same. (It doesn’t reflect the closed tab in its list of open files, but that’s tolerable as long as the list isn’t deleted.)

I can reproduce this bug with the following steps:

1. In SumatraPDF, enable the ‘Remember opened files’ setting.
2. Open several files,
3. Close and re-open SumatraPDF to ensure the opened files get remembered.
4. Open the settings file (for me, at C:\Users\<username>\AppData\Local\SumatraPDF\SumatraPDF-settings.txt) and scroll to the end. It should list all opened files, just after the line reading SessionData [.
5. Open one more file.
6. Re-check the settings file. It should reflect the newly opened file — or at least stay the same — but instead it reads:
   SessionData [ ]
   With no trace of any opened files.

[GitHubRulesOK]

Your observations about crash or system reset resulting in fresh settings are a known longtime issue that SumatraPDF needs to close cleanly to flush the volotile settings into a valid set for next start.

If the file is corrupted for any reason (manual edits or truncation by bad closure) It will replace the file with default entries which can not include _unknown_ history.

Most users can tolerate that, when its an exception, however frequent unexpected system updates raise the most gripes. I have "notify me" settings in windows to avoid that problem, so I can close SumatraPDF before system updates.

To guard against SumatraPDF update or other edits corrupting the file I have a start file to both back-up last session and store settings on closure.

Those still do not stop every case, and due to constantly testing edits of settings I can sometimes corrupt the file beyond redemption.

As you can see from the above it is imperitive that any opening of the settings MUST be closed BEFORE SumatraPDF can overwrite the file,, It is possibly an editor monitoring the settings file that blocks standard behaviour. Using Notepad usually does not block the writing of the file, but other editors may.

So starting afresh opening a file the file initially appears in file states but page navigation is not stored until I close the tab (and sumatraPDF)
Since only ONE tab was active there is NO session data (again a situation that can confuse issues)
Start a new session with two files (new file =a default file state but if one was "stored" its remembered settings are used). session data is blank
Closing the session even with the settings file viewed within notepad will result in the session data being stored in the background and works next time. UNLESS I acidentally save the open settings file which does not have session data i.e. I shoot myself in the foot.

When opening a third file the session data is no longer valid so is now "blanked" and multiple files can be closed and opened without needing to thrash the settings file. On clean closure of SumatraPDF the current session is then "remembered"

I agree the system is not foolproof, however it will work as designed in an ideal situation of no crashes or editor corruption.

[bradrn]

Your observations about crash or system reset resulting in fresh settings are a known longtime issue that SumatraPDF needs to close cleanly to flush the volotile settings into a valid set for next start.

If the file is corrupted for any reason (manual edits or truncation by bad closure) It will replace the file with default entries which can not include _unknown_ history.

I think that’s a slightly different issue to what I’m having. From what I can see, my issue has very little to do with crashing: it occurs only when I open a new file, at which point SessionData (but none of the other settings) is replaced with a blank list.

It is possibly an editor monitoring the settings file that blocks standard behaviour. Using Notepad usually does not block the writing of the file, but other editors may.

I’m pretty sure this isn’t the cause of my issue — it occurs no matter which editor (Notepad or otherwise) I use, or even if I don’t have the settings file opened at all.

[GitHubRulesOK]

It is natural for sumatraPDF to clear the old historic start-up session data when you open more files.
It also removes some other invalid settings EXCEPT it does not remove file states for missing files when "remember settings per file" is active.

In summary its "working by design"

to provide a "Last known good settings" command file I use this start.cmd in the same folder as the settings file with a desktop shortcut to click or drop files on.
It can't restore a failed session but allows me to restart the same as the previous session should there be a failure, so is best used when using a common set of documents.

IF exist "%~dp0SumatraPDF-settings.REC" IF NOT exist "%~dp0SumatraPDF-settings.txt"  COPY "%~dp0SumatraPDF-settings.REC" "%~dp0SumatraPDF-settings.txt"
call "c:\program files\sumatrapdf\SumatraPDF.exe"  %1 %2  -appdata "%~dp0" 
find /i /c "# Settings after this line" "%~dp0SumatraPDF-settings.txt" 
if %errorlevel%==0 COPY "%~dp0SumatraPDF-settings.txt" "%~dp0SumatraPDF-settings.REC"
pause

[bradrn]

It is natural for sumatraPDF to clear the old historic start-up session data when you open more files.

How so? To me this seems like a bug — surely it would be better to record each file as it is opened?

to provide a "Last known good settings" command file I use this start.cmd in the same folder as the settings file with a desktop shortcut to click or drop files on.

I have also set up something similar. I made a scheduled task which, every half an hour, makes a backup of my SumatraPDF settings. Unfortunately, this fails as soon as I open a new file (which is pretty often for me), at which point SessionData is cleared, making all my backups from then on useless.

[GitHubRulesOK]

I am not the programmer and have voiced my concerns as to how session storage could be changed. I am simply describing the fact that the issue of "robustness" in saving running state is exactly the same as its always been.

[bradrn]

Alright, thanks for explaining! I was just curious about what the motivation was behind this design, and if there is any way to fix it.

[GitHubRulesOK]

Unfortunatly the only temporary fix until the code is changed would be to regularily auto close and reopen the session with some test that session data has been populated, a task that suggests some external macro to reopen the session when closed and using a different means to abort at end of final session (I think one of the legit closure methods may involve a different errorlevel ?)

[bradrn]

That’s a bit of a pity — I was hoping that there would be another way to fix this. I already have been trying to close SumatraPDF regularly, but that’s proving to be a bit tricky given that I use it fairly consistently and so end up leaving it open throughout the day.

[GitHubRulesOK]

@kjk
It would be realy useful for advanced users to be able to back-up running "session data" such as "optionally" storing in settings.txt or a similar file when each file is opened or closed.

related to https://github.com/sumatrapdfreader/sumatrapdf/issues/1000# and https://forum.sumatrapdfreader.org/t/restoresession-not-working/2791
so providing a means to back-up running session data could aid with poor closures on system failing

[bradrn]

Seconded — it would be amazing if you could implement that!

[SumatraPeter]

I agree with @bradrn - there should be a better way to do this rather than wipe SessionData _from the settings file_ every time a new tab is opened, then write the latest values on successful exit. Perhaps read SessionData on program startup, manipulate _only_ the in-memory copy as long as the program's running and tabs are opened/closed, then finally overwrite the old SessionData on successful exit. This will at least ensure that a crash will leave the original SessionData untouched* so that the old state will not be lost. Yes, launching Sumatra after a crash would reopen all the old tabs and not reflect the state of the last session that crashed, but that would be a whole lot better than simply opening up with a blank slate.

*A crash might also possibly occur as the new SessionData is being written, leaving it in a corrupted state. In that case of course it would make perfect sense for Sumatra to wipe the corrupt SessionData when it is next launched, and open with a blank slate.

[bradrn]

Perhaps read SessionData on program startup, manipulate _only_ the in-memory copy as long as the program's running and tabs are opened/closed, then finally overwrite the old SessionData on successful exit.

That sounds like a good design as well.

[bradrn]

Thanks for fixing this so quickly @kjk! This issue has been frustrating me for quite some time. I assume this change will be included in tomorrow’s daily build — is that correct?

[kjk]

Yes, it'll be included in daily build (which actually is 'latest build' and usually gets created within an hour of making the change, unless there's a compilation error).

[bradrn]

In that case, I’ll download the latest build in a few hours and confirm that the issue is fixed.

(By the way, how will I know when a new build has been made? That webpage doesn’t seem to have an indication of which commit has been built.)

[kjk]

You can go to https://github.com/sumatrapdfreader/sumatrapdf/actions
If the there's a green checkmark for that commit, it's been finished and uploaded to daily builds.
Other options are: red means build failed. Yellow dot means build is in progress.

[bradrn]

That makes sense — I hadn’t realised the daily build was through GitHub Actions. Thanks again for helping me with my questions and fixing this so quickly!

[bradrn]

I have just confirmed that this fix works on my computer.

[kjk]

Thanks!