Forums Feature Suggestions mirc.ini backup/recovery on crash

After losing my mirc.ini due to computer crashing one too many times, and resulting in all remote files being unloaded, is there any chance we can get a fix for it?

One possibility would be to save a backup copy of mirc.ini on a timer, in addition to the usual mirc.ini's save routine (timer+on exit).

I assume this generally happens when mirc saves its ini on the exit event and things go wrong, instead of on the timed saves mirc uses. I assume this because I've run into the same problem when I had a script save settings both on exit and on a timer. The ini that was saved on exit would always run the chance of being corrupted or lost, the timed one wouldn't ever run into problems.

Anyway, would it be possible to have a separate temporary mirc.ini (that only gets saved on the timed save) as well as the regular mirc.ini (which is saved on timer+exit). On mirc startup it would check if [rfiles] is cleared then it should restore the data from the timed mirc.ini instead.

You can do this in a easy way your self.

Path should be replaced with as a example. C:\backup , and make shure the folder you copying from exist. For a time you can look at /help /timers . Or you can use the backup every time you closing mirc, take a look at /help on exit

Add the code to your remote. ALT + R in mirc. And you trigger it with: /backup

Yes I know, but i meant that it would handle this automatically, so they wouldn't need to type any commands.

I know how to script it myself, but that's not really what I was looking for. I wouldn't want the people who use my script to have to manually call any commands after a crash.

The only way to do it automatically is:
A) write a secondary 'launcher' program that checks the ini file for a cleared out [rfiles], and restore it with the backup.

B) Use an if (!$script(restore.mrc)) .load -rs restore.mrc in 'perform' -- since all their remote files would be unloaded when they start up mirc, we'd need to use perform or something else to reload it.

What I was suggesting was that it be built in to mIRC, since mirc seems to have its settings file corrupted more often than other applications.

Put mirc on a VM and do a few hardresets to see what I mean.

Sparta now offered you with exactly what you wanted and without experience in mSL it would've taken anyone about 10-20 minute reading the help files to create something like this after the idea was spawned.Sparta also offered options to do this automatically when the mIRC applications stops or at random times using a timer. Note that if you want it fully automated you can start the timer when mIRC starts etc.

Here are some thing you may want to read up on and try to combine with the script.
/help on start
/help on exit
/help /timer

You can check your mirc.ini size with $file(mirc.ini).size , if it dont match "on startup", then close and copy the new one to your mirc folder, can be done with a *.bat file. I using somthing like this i wrote for you in my own script. And i restore all files in mirc if 1 of them are missing, and making a backup of my files with the help of amount of times mirc have been started. every 5 times i make a backup.

Sigh. As I said, I already know how to do it in scripting, I'm an experienced scripter. But how are you going to trigger the 'repair' (or reloading the files) command on the start event when all your remote files are unloaded on start because of the crash?

You can't 'start a timer when mirc starts' as you suggest when mirc has unloaded every remote script file, and you can't rely on using any on * events.

You would still need to have them type commands in, or use mircs built in perform to wait until they connect. I'm not looking for a way to do it in scripting, I already know, and it's merely a bandaid, or a 'hack' to get it working.

What sparta suggests with a batch file would technically work, but then you'd have to make a separate executable 'launcher' run everytime you start your irc. That's not necessary, people shouldn't have to make launchers or scripts to keep their settings from being wiped. It's a client issue.


Scenario:


^- that all shouldn't be necessary, when the application could solve it by itself.