DOpus losing opened tabs ("Empty tab") on exit

After some more investigation into the issue with tabs being lost on restarts I've found 1 relatively reliable way to reproduce 1 bug of "Empty tab"s (but not another one of restoring a totally different layout instead the latest one):

  1. Open many tabs (save them in a tab group)
  2. (confirm that DOpus remembers them by closing and reopening a Lister)
  3. Exit DOpus
  4. Open DOpus and immediately click to Exit it from the tray icon (so normal close, not crashing the process or anything)
  5. re-open DOpus and see that some tabs are "Empty tabs"
    (restore tabs)

Checking the AppData\Local\GPSoftware\Directory Opus\State Data\openlisters.oll file I see the empty tabs are saved on "fast exit"

		<tabs1 active="0">
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />
			<tab />

Or sometimes these keys don't even get created (think if I manage to close fast enough?), so instead of

		<initial_layout>esExplorer</initial_layout>
		<tabs1 active="8">
			<tab />
		...(~20 empty tabs)...
		</tabs1>
		<tabgroup1>x</tabgroup1>
		...↑ this is the correct name of my backup tab group I used in step 1....
		<vars>

I get

		<initial_layout>esExplorer</initial_layout>
		<vars>

(by the way, if DOpus correctly identifies the tab group, can it use said tab group to restore instead of me doing it manually?)

I thought it might be due to this file being big ~9k lines due to an extension saving all undo tabs as lister vars. But then I've deleted all the vars, disabled all the extensions (the file is a few hundred lines now with a dozen lines / tab), and the issue remains - quickly closing DOpus writes empty tabs.

So this is some bug in the saving step - instead of overwriting the good state with the failed one DOpus should do an atomic save and only remove the old openlisters file data if the new one is successully saved

So it seems that DOpus can't save this data properly on exit, and that explains why on various windows update reboots that force-close apps it's lost, but if you close a Lister and reopen it, it's fine.

I've also noticed that some tabs have their folder layouts reset to "factory default" when I restore from a saved tab group (not in this testing), but that might have been just a result of "partial save" on exit so not the whole tab is lost, but just its layout?

This is using the latest Directory Opus 13.13.7

  • tried with Update default listed on an off, no effect
  • tried with all MSDefender options turned off (real-time protection etc), no effect
  • tried with an empty config (removing both local and roaming appdata dirs for Opus), same thing

I too see empty tabs from time to time and haven't been able to reliable reproduce this.

There are some other users reporting this already, including me, but still not possible to finally nail it down.

In my case, when I get empty tabs, I get this solved either switching the location of the tab or by pressing F5 to reload the content, although this does not always work either.

Maybe your steps will finally solve this riddle :wink:

And for reference:
https://resource.dopus.com/t/almost-all-opened-tabs-became-empty-tab-after-a-system-reboot/52556

https://resource.dopus.com/t/my-lister-tabs-become-empty-tabs-occasionally/52993

https://resource.dopus.com/t/tabs-are-empty-in-do-13/52615

As a side note: When quickling switching from one tab group to another (I've set up buttons with appropriate commands) it occasionally happens that a second instance of DO opens with the new group and there I frequently get empty tabs. This is reproducible on my side.

1 Like

Thanks for the extra context!
Do you ever get another bug: you open DOpus, tabs are there, but they are not the latest set? (my guess is that it's some old set that got saved correctly, and when the latest failed to save, the previous one got restored, but I haven't followed it closely to match to which set is actually restored, it's not like I remember all those tab changes :slight_smile: )

So far, I did not notic this behaviour.

Thanks for that! We've made a code change for the next beta - please let us know whether it helped or not!

Didn't fix it, the data loss manifests differently - instead of all empty tabs you get no tabs at all or half of tabs + 1 "empty tab", but it's still loses tabs

Still seeing empty tabs on my side.

Just downloaded update 13.13.8 from within a running DO, installed it and used restart option from the installer.

DO opens the previous listers and tabs and I immediately see empty tabs again, without loading, changing, refreshing anthing in the meantime...

State saved by the older version might still be wrong the first time the new version loads it.

Does the problem still happen on subsequent restarts after the first restart for the new version?

OK, so I closed all instances of DO and tried to reproduce the issue.
Belive me, I really tried hard to get the unexpected behaviour back :wink: to no avail so far :grinning:

To be fair, it was not always reproduceable in the past, too.

Nevertheless, the labels of the folders are correct now, but still missing the content from time to time. Means, there are no files visible unless I presse F5 to refresh.

I already reported this here, no scripts involved, btw.

I’ve noticed this behavior when opening tab groups.

For me, it depends on which tab is set as the active one. One of my tab groups contains 16 tabs, and I’ve observed that the content fails to display if any tab between #4 and #10 is set to active.

All the tabs refer to folders in /profile and share the same formatting via a wildcard path.

In my case this happens with tab groups, too.

I've got a tab group for example with 7 tabs. The first one is set to active. When loading this group, the first tab shows expected content, when switching to a different one, the lister is empty.

As a work around, refreshing the tab using F5, immediately shows the content.

BUT, cylcing through the tabs, shows the content after a while. I'm talking about seconds here and not minutes. Seems to be a kind of timing issues or a background process involved which takes some time to refresh the content.

Try to "pin" DOpus in the bottom right taskbar, so that when it launches you see it immediately, launch DOpus with a shortcut (keeping your mouse where its icon should be), right click and close it. Do it a few times with many tabs and see if all of them survive

By the way, it seems that the newer versions (also tested with the latest 13.4) might have improved something, but also made it much worse: quitting DOpus (not closing lister, but exiting DOpus) seems to retain the tabs, but closing Lister and opening a new one results in empty tabs every single time. No reboot or quick close necessary (though that also works, it seems that some of the tabs not in current view just get dropped or become empty)

I'm on 13.13 and encountered same stuff.
First time seeing this, I can imagine what actions lead to this.

Powered computer, and powered it down straight from Login screen before logging in. And clicking "Shutdown anyway". Could be OS or DO were doing something on start, but that was cancelled.

W10.

This remains my biggest annoyance with DOpus as every single restart I have to press a button restoring the latest saved state (and had to write a special plugin saving those states to be restored).

But I’ve just potentially discovered a more narrow cause: disabling Preferences / Launching Opus / Startup / Launch Directory Opus automatically on system startup with Don't open any Listers (otherwise the options below apply) and then restarting doesn’t seem to destroy my precious tabs anymore.

And after the DOpus is launched after a restart the openlisters.oll file is intact, so the issue in this case seems to be not data being lost, but that it’s simply being ignored when I open a new Lister. This new Lister behaves as though there were no listers saved on previous close. (although given the fact that openlisters isn’t updated when lister is closed, but only when DOpus is closed, maybe the fact that the file exists isn’t a good indicator??)

Haven’t tested it much, but hopefully this would be a partial workaround at the cost of a slower startup (the close/new is still not solved)

I'm just re-reading the first post here to refresh my memory, and some details that might be worth revisiting to try to work out why/when it's still happening.

  • Does this still only happen after you launch Opus and then exit really quickly, before the window has a chance to finish opening? Or is it happening more generally now as well?

  • Is a dozen or so tabs in a single window (still) enough to make it happen?

  • And does it happen if the only things in the tabs are all basic local folders (e.g. C:\, C:\Program Files, etc., but no archives or network servers etc.)?

  • Is the Preferences / Launching Opus / Startup / Backup open Listers automatically every option turned on? That can change when openlisters.oll is saved, so we should do our tests with the same setting you have.

Thanks!

then exit really quickly

I haven’t done any new stress-tests after figuring out a much simpler way to reproduce.

  • open lister with two local tabs

  • wait X min to make sure Lister is backed up (x=whatever is in my config, see below)

  • close the current lister (DOpus is opened in the tray)

  • openlisters.oll is intact and shows the list of those 2 tabs

  • open a new lister and see it has ~20 empty tabs and 3 local (but different from my test 2) tabs from, I guess, some other data source of previously?

  • openlisters.oll is reset to

    <?xml version="1.0" encoding="UTF-8"?>
  • after some time openlisters.oll is filled with the “correct” tab list (including empty tabs) and I see that lister vars are restored, I guess, from the same backup source as the tabs?

Is a dozen or so tabs in a single window (still) enough to make it happen?

2 is enough. It seems like it’s not about any preformance issues where you need a lot of tabs/fast close/reopen, but a more basic bug somewhere.

all basic local folders

Yes

backup open

Yes, these are my options

By the way, where is this backup located, maybe I can delete it, clearing that weirdly stuck layout with empty tabs, and see if it heals itself?