mIRC Home    About    Download    Register    News    Help

Print Thread
Page 2 of 2 1 2
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Just an update after close to a year. My personal impression from #mirc channels is this change seems to have had a positive effect. As in, it appears that there are fewer people complaining about losing mirc.ini than before. Of course this is not exactly a reliable statistic, but it's something.

However, it also appears that the issue is not entirely resolved yet. With the newer mIRC versions, so far I've seen two people report loss of mirc.ini after a power failure, with (as far as I can tell) very regular system and mIRC setups and thus no other probable explanation.

As such, it might still be worth trying slightly heavier ways to preserve mirc.ini, or at the very least printing some information that may help identify the root cause. For example, if mirc.ini cannot be loaded but the default directory contains other mirc-generated files that are never installed by default (is remote.ini among those?), print some information about why mirc.ini couldn't be loaded (missing/empty/corrupted) or so. After all, with the new situation, in theory mirc.ini should never be lost. Anyway that's my 2c..


Saturn, QuakeNet staff
Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
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:
https://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.
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Yep, good points. Some sort of backup system would definitely be a good idea I think. Most people that lose mirc.ini, for whatever reason, have nothing to fall back on and have to start from scratch. I don't think a scripted solution would help much: those who lose mirc.ini tend to have no idea that that was something that could possibly ever happen anyway.

As an additional, alternative, least-resistance kind of suggestion towards making mIRC create mirc.ini backups: I've often wondered why the installer doesn't do just that. Right now (as I understand it) the installer backs up only files that are about to be replaced, but I don't think it has to be that way. In fact it would make more sense to me if the installer backed up crucial files no matter what was being replaced at installation time [*]. Having a copy of mirc.ini from before the last upgrade is probably good enough for most people in these situations, and this change can probably easily be made in the installer without affecting anyone negatively. Note that in this case, restoring the backup after a problem would be manual, but that's still a whole lot better than having nothing.

[*] After all, a newer mIRC version may inadvertently misinterpret and mess up an older mirc.ini - at least in theory, because I don't think this has actually happened yet. But this is unrelated to the thread at hand anyway.


Saturn, QuakeNet staff
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
I would propose that mIRC create session backups of the files that it opens or modifies. That is, mirc.ini, servers.ini, urls.ini, control.ini, users.ini, vars.ini, popups.ini etc, as well as all loaded scripts and alias files. I recognize that's a lot of files, but it tends to be that all of these files can disappear.

When mIRC launches, as it searches for mirc.ini, it also checks for any mirc.ini.sessionbackup files in those same locations, and compares their last-modified date to determine which one to use. If the sessionbackup is newer than the mirc.ini it finds, or if no mirc.ini is found, then prompt the user about restoration.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Page 2 of 2 1 2

Link Copied to Clipboard