Home / RestoreSession not working

I have run into this problem several times on different machines after installing Sumatra.

Sumatra does not restore the pdf-files next time which were open when Sumatra was closed, although I set it up to do so.

Here is the settings-file of an installation where this is happening:

# For documentation, see http://www.sumatrapdfreader.org/settings3.1.html

MainWindowBackground = #80fff200
EscToExit = false
ReuseInstance = true
UseSysColors = false
RestoreSession = true

FixedPageUI [
	TextColor = #000000
	BackgroundColor = #ffffff
	SelectionColor = #f5fc0c
	WindowMargin = 2 4 2 4
	PageSpacing = 4 4
]
EbookUI [
	FontName = Georgia
	FontSize = 12.5
	TextColor = #5f4b32
	BackgroundColor = #fbf0d9
	UseFixedPageUI = false
]
ComicBookUI [
	WindowMargin = 0 0 0 0
	PageSpacing = 4 4
	CbxMangaMode = false
]
ChmUI [
	UseFixedPageUI = false
]
ExternalViewers [
]
ShowMenubar = true
ReloadModifiedDocuments = true
FullPathInTitle = true
ZoomLevels = 8.33 12.5 18 25 33.33 50 66.67 75 100 125 150 200 300 400 600 800 1000 1200 1600 2000 2400 3200 4800 6400
ZoomIncrement = 0

PrinterDefaults [
	PrintScale = shrink
]
ForwardSearch [
	HighlightOffset = 0
	HighlightWidth = 15
	HighlightColor = #6581ff
	HighlightPermanent = false
]
CustomScreenDPI = 0

RememberStatePerDocument = true
UiLanguage = de
ShowToolbar = true
ShowFavorites = false
AssociateSilently = false
CheckForUpdates = true
RememberOpenedFiles = true
EnableTeXEnhancements = false
DefaultDisplayMode = continuous
DefaultZoom = fit page
WindowState = 1
WindowPos = 301 1 1199 1021
ShowToc = true
SidebarDx = 310
TocDy = 0
ShowStartPage = true
UseTabs = true

FileStates [
	[
		FilePath = C:\Users\XXXX\Documents\Robert Marschall sorgt für neue Schlusslichter im Volksbegehren-Ranking - Parlament - derStandard.at › Inland.pdf
		Favorites [
		]
		IsPinned = false
		IsMissing = false
		OpenCount = 1
		UseDefaultState = false
		DisplayMode = continuous
		ScrollPos = -1 -1
		PageNo = 1
		Zoom = fit page
		Rotation = 0
		WindowState = 1
		WindowPos = 301 1 1199 1021
		ShowToc = false
		SidebarDx = 310
		DisplayR2L = false
		ReparseIdx = 0
	]
]
SessionData [
]
TimeOfLastUpdateCheck = 0 0
OpenCountWeek = 479

# Settings after this line have not been recognized by the current version

What is wrong here?

This is a common issue in that if there is only one file open (not two or more) when SumatraPDF is closed the session is not stored as “multiple files” to be opened One simple way to store a favourite file or up to 10 is to pin them to the start screen or add to the favourites list

Well, I shortened the list of opened files for not spamming with unnecessary data. There are actually 5 files to be opened when sumatra starts.

Odd and an edited settings file makes it difficult to see any cause.

One good way to check this behaviour is to delete the settings file so it is “fresh built” by the system then open two tabs and use top right X close SumatraPDF session and restart from shortcut to check they both open next time.
If you close one of the tabs before closing the session then it will by design (good or bad ) not “remember” the remaining one

OK, here is the complete settings file:

MainWindowBackground = #80fff200
EscToExit = false
ReuseInstance = true
UseSysColors = false
RestoreSession = true

FixedPageUI [
	TextColor = #000000
	BackgroundColor = #ffffff
	SelectionColor = #f5fc0c
	WindowMargin = 2 4 2 4
	PageSpacing = 4 4
]
EbookUI [
	FontName = Georgia
	FontSize = 12.5
	TextColor = #5f4b32
	BackgroundColor = #fbf0d9
	UseFixedPageUI = false
]
ComicBookUI [
	WindowMargin = 0 0 0 0
	PageSpacing = 4 4
	CbxMangaMode = false
]
ChmUI [
	UseFixedPageUI = false
]
ExternalViewers [
]
ShowMenubar = true
ReloadModifiedDocuments = true
FullPathInTitle = true
ZoomLevels = 8.33 12.5 18 25 33.33 50 66.67 75 100 125 150 200 300 400 600 800 1000 1200 1600 2000 2400 3200 4800 6400
ZoomIncrement = 0

PrinterDefaults [
	PrintScale = shrink
]
ForwardSearch [
	HighlightOffset = 0
	HighlightWidth = 15
	HighlightColor = #6581ff
	HighlightPermanent = false
]
CustomScreenDPI = 0

RememberStatePerDocument = true
UiLanguage = de
ShowToolbar = true
ShowFavorites = false
AssociateSilently = false
CheckForUpdates = true
RememberOpenedFiles = true
EnableTeXEnhancements = false
DefaultDisplayMode = continuous
DefaultZoom = fit page
WindowState = 1
WindowPos = 301 1 1199 1021
ShowToc = true
SidebarDx = 310
TocDy = 0
ShowStartPage = true
UseTabs = true

FileStates [
	[
		FilePath = C:\Users\x\Documents\Robert Marschall sorgt für neue Schlusslichter im Volksbegehren-Ranking - Parlament - derStandard.at › Inland.pdf
		Favorites [
		]
		IsPinned = false
		IsMissing = false
		OpenCount = 1
		UseDefaultState = false
		DisplayMode = continuous
		ScrollPos = -1 -1
		PageNo = 1
		Zoom = fit page
		Rotation = 0
		WindowState = 1
		WindowPos = 301 1 1199 1021
		ShowToc = false
		SidebarDx = 310
		DisplayR2L = false
		ReparseIdx = 0
	]
	[
		FilePath = C:\Users\x\Documents\Strache sieht _Bevölkerungsaustausch_ als _Begriff der Realität_ - FPÖ - derStandard.at › Inland.pdf
		Favorites [
		]
		IsPinned = false
		IsMissing = false
		OpenCount = 1
		UseDefaultState = false
		DisplayMode = continuous
		ScrollPos = -1 -1
		PageNo = 1
		Zoom = fit page
		Rotation = 0
		WindowState = 1
		WindowPos = 301 1 1199 1021
		ShowToc = false
		SidebarDx = 310
		DisplayR2L = false
		ReparseIdx = 0
	]
	[
		FilePath = C:\Users\x\Documents\Presserat rügt Wochenzeitung der Grazer wegen Wunderheiler-Artikels.pdf
		Favorites [
		]
		IsPinned = false
		IsMissing = false
		OpenCount = 1
		UseDefaultState = false
		DisplayMode = continuous
		ScrollPos = -1 -1
		PageNo = 1
		Zoom = fit page
		Rotation = 0
		WindowState = 1
		WindowPos = 301 1 1199 1021
		ShowToc = false
		SidebarDx = 310
		DisplayR2L = false
		ReparseIdx = 0
	]
	[
		FilePath = C:\Users\x\Documents\Türkis-grünes Programm  Keine Stimme für die direkte Demokratie - derstandard.pdf
		Favorites [
		]
		IsPinned = false
		IsMissing = false
		OpenCount = 1
		UseDefaultState = false
		DisplayMode = continuous
		ScrollPos = -1 -1
		PageNo = 1
		Zoom = fit page
		Rotation = 0
		WindowState = 1
		WindowPos = 301 1 1199 1021
		ShowToc = false
		SidebarDx = 310
		DisplayR2L = false
		ReparseIdx = 0
	]
	[
		FilePath = C:\Users\x\Documents\Eltern\Busfahrpläne 2020[1].pdf
		Favorites [
		]
		IsPinned = false
		IsMissing = false
		OpenCount = 1
		UseDefaultState = false
		DisplayMode = continuous
		ScrollPos = -1 217
		PageNo = 2
		Zoom = fit width
		Rotation = 0
		WindowState = 1
		WindowPos = 301 1 1199 1021
		ShowToc = false
		SidebarDx = 310
		DisplayR2L = false
		ReparseIdx = 0
	]
]
SessionData [
]
TimeOfLastUpdateCheck = 0 0
OpenCountWeek = 479

# Settings after this line have not been recognized by the current version

Because you are editing paths I can’t tell if those files were for example in a temporary cache, the reason I say that is the [1].pdf ending on one of the file names and the use of italics
The files to be opened can be affected by non latin characters

Try it with just two simple file names in your ordinary documents folder.

The odd part is that at the end of the settings file there should be a section that you are not getting showing that two tabs were still active when session was closed like this

SessionData [
	[
		TabStates [
			[
				FilePath = C:\Users\name\Downloads\Delorean-Workshop Manual 96B.webp
				DisplayMode = single page
				PageNo = 1
				Zoom = fit page
				Rotation = 0
				ScrollPos = -1 -2
				ShowToc = false
			]
			[
				FilePath = F:\Data\Samples\azw&mobi\Ubunchu!-KO.azw
				DisplayMode = facing
				PageNo = 1
				Zoom = fit page
				Rotation = 0
				ScrollPos = 0 0
				ShowToc = false
			]
		]
		TabIndex = 2
		WindowState = 1
		WindowPos = 239 155 805 618
		SidebarDx = 289
	]
]

There are at least two other potential causes that I cant tell from your sample

One is your user name (A rare possibility that has caused other apps to have problems say with Korean characters in names)

The other is the way you close the session say if you hit Q Q Q which will close the tabs one by one

I am sorry but I am not sitting at the machine where the problem occurs, so I can not test right now.

I am not understanding why you bring in “editing paths” and “temporary cache” issues.

As you can see the files in question are in the “ordinary” “documents” folder provided by the operating system for the user “x”. The only ting I edited out is the real user name and replaced it with “x” because of privacy reasons. I do not see the logic you are arguing with.

The files are real and do exist at the given locations. If this wasn’t the case how could I open them from exactly there, have it displayed in sumatra, sumatra writing their names and location into its settings file? I can not follow your reasoning …

Why a file name ending with an “[1]” gives you reason for suspicion that there is somehting wrong I also do not understand. Most browsers automatically add “[n]” to a file name if a file is downloaded and there already exists a file with the same name.

“italics” issue: I am copying the text from a copy of the original sumatra-settings file, which as already mentioned rests on a different computer. The copy is a pure txt-file. Testwise I opened it with about half a dozen text-editors to see if there is any “italics”-code hidden. No, it is not. It is the forum software that does this. You can also see this withthe lines in “bold” and bigger size, which actually are copied from the original sumatra txt-file. I did not edit here either, it is the forum “editor” who interprets and displays it that way.

If the forum software is changing the names it suggests the names are not “conventional ASCII/ANSI” characters such as under_score and › notoriously can cause OS file handing issues. Especially a problem when crossing over between platforms. [1] is usually a cache issue (1) is normally a duplicated file.

My guess at this point is as you say probably not the names at fault
The lack of session data suggests at the time of capturing the settings there are NO tabs open to restore.

The most common reason is that only one tab is visible at that time since the others have been closed by the user prior to closing the session

Well, no “SessionData” written by Sumatra certainly is the reason why no files are reopened. Thank you for spotting this!!!

But well, this is sumatras problem (bug), because this was certainly not because there was only one file (or none at all) open when I closed Sumatra. I can reassure you I played around with this issue for hours (several times in the past years on different machines affected by this behavior) and tested all and everything possible before I came here.

So there is a bug and it exists since years. Should be fixed.

Next time I have access to the affected system I will delete the settings file, start sumatra, have it set up to my wishes, close it. Sumatra should write a new settings file. Then I will have several pdf files opened. And have them still opened when closing sumatra. Will report if the “SessionData” section will be written to this time.

Anyway, there is a bug that should be fixed.

The “Issue” is covered by https://github.com/sumatrapdfreader/sumatrapdf/issues/1055 and https://github.com/sumatrapdfreader/sumatrapdf/issues/1000

Never faced this bug yet in all these years… Not saying there’s no possibility of a bug, but it’s unlikely to get fixed unless you can find a way for others to reliably replicate it. I tried by replacing my settings file with yours and copying 5 PDFs using the same names and paths as in your settings file (with ‘x’ replaced by my username obviously), and Sumatra dutifully saved and reloaded their tab states.

If you experience the same issue even after deleting the existing settings file then let us know and we can try to look into it a bit more to see if we can replicate at our end.

If you copy/pasted my settings-file and the pdf-files reloaded automatically when sumatra was started then a miracle happened.

Because in my settings-file the section “SessionData” is empty, which is the reason why the files are NOT loaded.

And here is the bug, because you can see from the settings file variables like RestoreSession=true and RememberOpenedFiles=true that sumatra should keep record of the files that are open when closed to be opened at the next run. But it does not, mystically. At least some time on some installations.

In fairness to SumatraPeter I think the point he was making that using substitution your file settings did work as even without me testing they would likely do for me.
The “bug” is the not unreasonable impression that with those settings one could expect that SumatraPDF would remember the history prior to closure which in certain usages it does.
There are two known main problems with the way volatile “SessionData” is stored.

1. When using multiple tabs The file must be closed in a controlled fashion (ALT F4 or CTRL Q or if set to exit then ESC or simply top right X Close app etc.)
   If the plug is pulled (say by an update / brownout or “Quitting” the session using successive Q) Then the data can not be flushed from memory into the settings file.

1a. If your not using multiple tabs or have one file open in a tabbed window with a second or more opened as a session via new window the only controlled way to close multiple (two or more) windows and restore them is using File > Exit CTRL Q e.g. in this case using esc to exit or close window will not close a session just each window in turn

2. There must be two or more tabs / linked windows active to form a “session” (hence the problem above of using Q or CTRLW) at the time of controlled closure otherwise a permanent flush to file can not be triggered.

I never said they reloaded automatically the first time. That was obviously never going to happen because your settings file contained only FileStates and not SessionData/TabStates. I didn’t feel the need to elaborate, but if you must know I started up Sumatra, the home page showed empty thumbnails for the PDFs, I clicked on each one, scrolled to some random page, closed Sumatra, then reopened and there they all were, right were I left each one of them. Clearly on my system both FileStates and SessionData/TabStates are being saved/reloaded.

Like I said, I have never faced this situation on any of the systems I have Sumatra installed on. If we (and specifically, the program developer) cannot replicate this situation where FileStates are saved but not SessionData/TabStates then naturally it’s going to be extremely difficult to fix the problem.

@kjk: Can you think of any possible scenario where there are multiple tabs open, Sumatra is closed cleanly and yet the data to be serialized contains FileStates but not the corresponding SessionData/TabStates?

@SumatraPeter but mainly for @DoPe to consider

One scenario I forgot to mention
If the user was changing the advanced settings and closes the session in a valid way
THEN at that subsequent point saves settings.txt overwriting the saved session then obviously SessionData would most likely be totally lost.

@GitHubRulesOK: Would that explain the existence of only FileStates but not the corresponding SessionData/TabStates in the settings file? In the normal course of things either both or neither should be present, right? Unless someone deliberately edited out the SessionData/TabStates section, the presence of one but not the other does seem to indicate that something has gone wrong somewhere.

My experience suggests SessionData is written into the file by closure it is not generally tracking files opened and closed only those open during controlled closure. Many external factors can disturb that final save. Another posibility that I have not highlighted is the effect of some more agressive antivirus seeing file acess at that time and potentially borking that flush of data. I have personally advocated users back-up a copy of favourite / fixed session preferences. Or ideally switch to a multiple external file system of collective preferences, similar to that about to be introduced by .vbkm.
Mission critical robustness requires an element of redundancy which is not present in the current methods. But then SumatraPDF is not touted as for military grade usage.

Could you please rephrase - I don’t understand what you mean.

Rephrase
Settings >Advanced Options opens the SumatraPDF-settings.txt file in an editor application (usually Windows Notepad)
Some settings can be altered in notepad and will take immediate effect in SumatraPDF once the change is detected on saving in Notepad.
Some settings can be altered and saved in notepad but need R(efresh) in SumatraPDF to be forcibly actioned at the time rather than later.
Some affecting say screen layout of tabs need SumatraPDF to be closed and restarted to rebuild the interfaces.

If you look at the end of file where SessionData is stored you would probably see there is nothing there at run time whilst other parts of the file could change as you close and reopen the settings file.

The file is constantly changing but depends on refreshing in different ways at different times.

So if you have Advanced settings visible in Notepad and SumatraPDF is about to be closed notepad should be closed first such tht SumatraPDF can store the SessionData on its controlled closure.

image1635×420 82.5 KB