Zugg Software :: View topic - Lost settings

Posted: Sat May 05, 2012 12:54 pm

Using CMUD 3.34, having some issues that very much concern me.

I've had some issues a few times now, where if CMUD is not shut down properly (this morning, the client completely deadlocked, which was the first time I've had that), there is data loss. Mostly missing triggers and aliases. I can't seem to figure out any pattern to what data is lost.

All well and good, right? I've got backups... Of course, 16 backups, each run every 8 hours.

The data is missing from all 16 backup files. Sifted through all of them both through CMUD and through my favorite text editor and grep. Nothing.

This is _extremely_ disconcerting. This tells me that I could have potential for major data loss (this current issue will probably cost me 4 hours of determining which aliases/triggers are missing and re-creating them). Also disconcerting is that I don't _know_ that my stored PKG files or their backups are truly complete.

In a paid commercial package, I'm extremely concerned by this.

I hate to ask for workarounds, but can I get some advice on:
1) Is there a way to run a tool to validate that all triggers/aliases/etc that are currently loaded in memory are _actually_ saved to disk?
2) Is there a way to get a _guaranteed_ good backup file that I know contains all my data (preferably without me having to check the data file by hand to validate it)?

-Rob

Posted: Sat May 05, 2012 5:05 pm

For a garunteed good backup... put completed sections of code that are not to be updated into separate packages in the package library.
The separation will also mean that if one package becomes corrupted, that all your data wont be affected.

Export to XML as well.

The syntax checker can only do so much.

Posted: Tue May 15, 2012 2:14 pm

I'm not certain that that the below method is working for me either.. just lost a few variables this morning that were a serious pain to recreate. Variable hadn't been changed in at least a week, was in a package that wasn't being touched, and turns out it was not written to disk in any of the prior packages.

With hundreds of variables and triggers, and having NO IDEA whether the data in memory is being written to disk, I have some serious concerns using this package at all. The amount of time wasted trying to even determine what data is missing after a crash or shutdown, then correcting the problems is worth almost enough to spend the effort to learn and switch to another client.

I can write XML to disk periodically, run #SAVE commands, etc... but that in no way gives me an integrity check to tell me that what is in memory is _actually_ written to disk.

Is anybody else having similar issues? If I'm unique in this (though it's happened numerous times to me), then perhaps there is something about my system causing the issues.

Wizard Joined: 22 Mar 2007 Posts: 2320

Based on what you are describing, something odd is going on. In Zmud, data was not written to the disc until logout. But Cmud writes changed variables to the disc as soon as you change it. That way, you do not lose data if Cmud freezes or crashes.

This sounds like you have a corrupt package file. It is likely that the data is still mostly in your package, but the XML has been messed up. If your package is corrupted, you will continue to have problems with data appearing to change or disappear, until you fix the corruption. And, naturally, the backups will be copies of the corrupted file.

The usual method of fixing a corrupt file is to export the package, then import it into a new clean package. The export/import process usually fixes broken XML tags, and usually recovers most of the "lost" data in the package. You may still need to clean it up a bit, and rebuild some of it, but this /should/ fix most of it if the problem is package corruption. But if it's been corrupted for a long time, you may have built up a lot of cruft in the corrupted parts.

Posted: Tue May 15, 2012 4:17 pm

That sounds like a good plan. I will plan on doing that shortly and monitor for further issues.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Actually, any change made to any setting is written to disk as soon as you click away to a different setting. This is a relatively new approach for settings files, but it has always been done this way for the mapper in ZMud. If you just click on the Compile tabs, it just updates the in-memory database.

As for corruption, keep in mind that CMud is storing all its data in memory during use--system properties (cmud.ini or .cfg or whatever the file is named now), map data, package files (include any default packages like EnglishKeypad or ClickableURLs), layout files, and toolbar (*.tbr, can have one for the session, the mapper, and the package editor) files. Errors in any of these can potentially manifest in other files, for no other reason than that happens to be where the error finally "broke" CMud. If you're going to do one package, it's much better to also do ALL of your packages, and it's even better if you reset the layout on top of that.

Posted: Thu May 17, 2012 1:50 am

Wow, getting the data out of my old setup was a little challening... re-importing the data is a nightmare. I deleted the Session completely and associated files after exporting everything as well as all package files in the packages directory. Created new session, and started importing....

I can only assume that some of the data that I'm re-importing is somehow corrupt, as I'm having error after error (exception errors, total crashes and deadlocks), particular when dealing with Window objects (I currently have a Window object that exists, but does not show up in the settings screen at all).

Kinda leaning towards a complete uninstall and reinstall at this point, as it is likely that some of the built-in packages (clickable URLs, etc) is corrupt...

I'll update on the progress, but at this point it's a really huge mess.