Some things that might help avoid or mitigate problems with mirc.ini vanishing:

1. Related to the problem described in this link, exempt mirc.ini or $mircdir from your virus checker, to avoid lengthening the time it takes mIRC to write to disk, shrinking the time window for something bad to happen during a crash.

Html:
http://forums.mirc.com/ubbthreads.php/topics/260688/Re:_Windows_8.1_/write_very_ve#Post260688


2. Do a little housecleaning on your own mirc.ini. I don't know whether the problem is related to the size of mirc.ini or not, but several years ago when people in #channel were having this problem, after I suggested they trim the size of their mirc.ini smaller than 8kb, it anecdotally seemed to lessen the frequency of mirc.ini getting reset.

The default mirc.ini has a long list of favorites, of which most people don't plan to ever visit many of them, so you can trim them off the list. Before pruning things, you might wish to make a backup copy of mirc.ini to have a list of these no-longer-favorites. The default list of 'favorites' has over 6 dozen channels listed, adding nearly 2kb to the filesize.

Another group of deadwood you can prune from your mirc.ini is within the [windows] section, where there can be a wchannel-$network, wstatus-$network, etc for every $network you've ever been to and never plan to visit again. Many of those lines seem to be created for no benefit, as all the wdccs-$network and wdccg-$network lines I found seem to be identical to the defaults which don't include a network name.

The [fonts] section might also contain font settings for obsolete channels. I even found mine containing font settings for query windows with specific nicks.

3. mIRC could implement a backup system to allow you to restore mirc.ini from a backup, instead of just resetting back to default settings. It should be sufficient to either make the backup at regular intervals or only after non-trivial changes. It looks like mirc.ini is constantly being updated by the value of the online timer, so re-saving the backup for those changes is pointless. Just like many other programs do, mIRC could use the mirc.ini.bak backup if during startup it determines mirc.ini is defective, rather than just restoring all settings to default.

4. In lieu of mIRC creating a backup system, it's easy to script one of your own. This example creates a backup filename for each day of the week, so if you discover your settings have been reset, you can quit mIRC and copy the newest good backup on top of $mircini and restart mIRC. In this example, it makes an hourly backup of both mirc.ini and the file where global variables are saved to disk. Unless you feed it a $1 parameter, it won't make a backup unless mIRC has been running for at least an hour. This prevents a variables backup from being replaced immediately by a main variables file which was reset to default during a crash.

Code:
on *:START:{ mircini_backup }
alias mircini_backup {
  if (!$timer(mircini_backup)) timermircini_backup -o 0 3600 mircini_backup
  if ( ($uptime(mirc,3) !isnum 3600-) && (!$1) ) return
  saveini
  var %ini $nopath($mircini)
  var %bak backup_ $+ $asctime($ctime,dddd) $+ _ $+ %ini
  echo -s Making safety backup of %ini as %bak
  copy -o $qt($mircini) $qt(%bak)
  var %varsfile $readini($mircini,rfiles,n1)
  if (%varsfile != %ini) {
    var %varsbak backup_ $+ $asctime($ctime,dddd) $+ _ $+ $nopath(%varsfile)
    copy -o $qt(%varsfile) $qt(%varsbak)
  }
}

Just having 1 backup is enough to protect against the BSOD bug, since resetting mirc.ini to default removes this snippet and all Alt-R scripts from being loaded, so your backup won't get replaced by mirc.ini immediately after it's been reset. However, it also helps defend against your variables file being reset, giving you a week to notice the problem.

Edit: As for the issue of it being possible that backups made by mIRC could get corrupted just like mirc.ini, I agree that it's possible - but the chances are greatly reduced if backup saves are kept separate from when writes to mirc.ini are made. That means saveini and the equivalent routines which write to mirc.ini at shutdown should not write to the backup too. If mIRC keeps itself from writing to the backup and to mirc.ini within 60 seconds of each other, it's very unlikely that they'll both be corrupted, and people would much rather use a backup that doesn't have the last 15 minutes worth of configuration changes than having mirc.ini reset back to date of install.


Last edited by maroon; 20/07/17 11:25 PM.