Closing another gap: avoid losing opened tabs by periodically saving them to a group

Buttons/Scripts
,
1

If you've ever opened DOpus to a list of 20 Empty Tabs instead of your carefully ordered working folders, or even to an empty list of 1 tab, this script is for you!
It allows you to avoid data loss of your precious tabs by periodically automatically saving opened tabs in a Tab Group.

You can configure

  • how often this happens (≝once / 10min)
  • max number of groups to save (≝5)
  • the name of the group (but not yet its parent folder, see known issues below) (≝unimaginative Backup \ TabGroup #)
  • whether to close other tabs on restore globally (but this you can change in DOpus settings individually before restoring)

So you'd have something like this

Tab menu

backup.TabGroupSave🕘_TabMenu
backup.TabGroupSave🕘_TabMenu704×227 13.4 KB

Or settings menu

backup.TabGroupSave🕘_Settings
backup.TabGroupSave🕘_Settings656×395 19.9 KB

Known issues:

  • while the script supports multiple listers and saves 1 tab group per lister, as far as I understand there are no permanent lister IDs, so this uses lister's position in a list of listers :slight_smile: that DOpus returns as its ID, which can change across DOpus restarts, so Lister # 1 in a previous backup operation might be different from Lister # 1 in the next one

  • due to this issue I can't hide these autosaved tabs in a folder (ideally each lister would get its own), so unfortunately they pollute the general list instead

  • :warning: deletes old tab groups starting with user defined prefix + index, so it's important to pick a prefix not used in other tab groups to avoid them being deleted.

  • while the script exposes a custom command to do the backup, invoking this command "too fast" (a few times / second) results in skipped backups with the risk of deleting older backups

  • also not sure what would happen in the rare case of race conditions when you manually update tab groups and in that very moment the script decides to save its own group.

  • script isn't extensively tested

The script itself:
backup.TabGroupSave🕘.opusscriptinstall (6.0 KB)

2

It's a bit weird how this is apparently an incredibly common issue and yet no one is able to give us steps for reproducing it :slight_smile:

1 Like
3

That's not entirely true, I've given you 1 unreliable way to reproduce

, or opening DOpus too quickly with 2 shortcuts to open 2 folders, resulting in 2 instances (which happens if the tray dopus hasn't started yet)

but also there is nothing weird about it - for example, the above method is unreliable, it doesn't even reliably open 2 Opus instances, let alone lose the tabs. Think it mostly bugs on system startup when CPU/disk use is high?

But otherwise I have no clue what the cause is, so maybe this method is totally unrelated and the only negative effect is 2 DOpus instances, which isn't a big deal, and the tab loss is for an entirely unrelated reason.

For example, why would I ever see all tabs replaced wtih an "Empty Tab"? Was layout backup process unreliable? Does this process not verify the backup before overwriting the old one? If it's interrupted by OS restart or a DOpus crash, would it lose data or simply fail to update the old backup? Only you know the mechanics) and how to troubleshoot it to reproduce it, so periodically saving tabs manually was a better workaround, and now using this script should be the "final" workaround for me.

Also it's not like this happens very frequently for me to see a pattern (not that frequency would automagically reveal the true nature of a bug :wink: )

Maybe if you could come up with an easier method of tracking, I could catch it locally. Like, where is the layout saved? Does it store previous versions? Then maybe whenever I get empty tabs again I can simply open the last 5 backup files and see "oh, on backup #3 all tabs lost their paths"