Forums Bug Reports Random file corruption (most notably mirc.ini)

Hi,

I have had a problem from time to time with different mIRC versions, but it is intermittent and I have no way to reproduce it consistently, nor any idea when or what sequence of events occurs to cause it. It may not even be a problem with mIRC itself.

The problem is this: Something happens, and mirc fails to completely write out an INI or script file (most often the corrupt file is mirc.ini, but it has corrupted other files at times). It gets chopped, and completely messes up mIRC's operation.

As I stated, I cannot reliably reproduce this bug (although I have read a thread on non-paged memory issues, and wonder if this is related..) However, I can give some generalized info on when I've noticed it most/least:

• Any system crash, especially those which force a reboot often, but not always, have this problem.
• It does seem to happen more often if mIRC has been running for long periods of time (I leave mIRC running almost 24/7.)
• It rarely happens when totally "idle"--that is, when I sit in my private channel without anything happening to trigger any events and scripts (normal operation, like server ping-pongs do not seem to cause it). However, the act of starting or exiting mIRC has sometimes resulted in this happening.
• When, where and what files it affects seems random, with mirc.ini seeming to get hit the most. At times, it even affects files which (as far as I know) never should have or needed an update/write (no changed settings, no scripts running which wrote anything to disk, etc.)
• I have noticed this problem for the last few versions (at least since version 4.x, when I switched to mIRC). I have just upgraded to 6.3, so I do not yet know if it continues to have this problem.
• Likewise, the OS, hardware, drivers, etc, do not seem to have any effect either way. I have seen this problem occur on different computers, with different configurations, drivers and OSes.
• I even went so far as to write a batch file that makes a backup of all changed files prior to starting mIRC, and again after it exits; as well as used a file-change notification utility to log when any file in the mIRC folder (and it's subs) gets modified. As this has worked well for me, perhaps mIRC could do something similar.. (IE, make a backup of any files it changes/writes to, and perhaps even keep a "journal" of changes from the point of backup, to help track through changes made to see when the problem occurs.)
• I have tried a few things try to reproduce the problem; even forcing a system crash/reboot, hitting the reset button, etc. The problem has never occurred during any of those tests; It seems to only happen sometimes when those events occur on their own.

Please let me know if I can provide any further help or info.

Cas

Anytime a program is in the middle of writing to a file, such as an INI file and it's terminated abruptly from a crash, you have a good chance of the file getting corrupted. I'm not sure there is much you can do about that. Note that this is only when the file is being written to at the time of the crash.

Yes, that much is a given, and I assumed obvious.. ;-)

To clarify tho, what I am saying is that from my observations, there is a relatively much higher incidence with mIRC than any other programs I usually run. That makes me ask "why?" Especially if I'm not doing anything at the time that gives me any reason what-so-ever to think mIRC should even be writing something to disk (other than log files). Actually, unless I click a save toolbar button/select a save file menu item, it almost never happens in any other app, since few write anything to disk without an explicit user action. I had also stated that I've tried to force some crashes/reboots to reproduce it, with no success. At the hardware level, writes happen so fast, that you have to be doing something unusual with the code or the crash happen so randomly that it hits that rare moment in mid-write.

General programming experience tells me such behaviour would indicate I should poke around the code that handles the logic of when/what/where to write, as well as the routines which do the actual writing, and consider if it is doing something "unusual". For example, opening a file, seeking the begining, truncating, writing only a single line, forcing a flush, writing another line, flushing again, etc. Besides being extremely inefficient, it causes a much larger number of actual writes to disk (at the hardware/system level, data is transfered to/from the disk in entire 512-byte sectors or more. The OS doesn't actually write to disk unless flushed, or it has a full buffer of data to transfer, etc. More actual writes just gives more places for problems to creep in), keeps the file open longer (to us humans, 10ms vs 100ms is trivial; but to a computer, it's a very very long time..), and other things which a crash could disrupt.

Normally, I couldn't imagine a programing writing a disk file this way because of the inefficiencies I mentioned.. However, the routines used to write an INI file may very well operate in a similar manner since it may write to different sections/topics and items at different times, causing the write routines to bounce back and forth around the file.

Sorry if my noting the crash issue seemed obvious or stupid--I don't know the mIRC source code, so I can't really tell what info is truly relevant. I can only give all the info I can to help those who do the coding narrow down to where the problem might be.

mIRC should be closing the file handle to mirc.ini when it's not writing anything to it. There shouldn't be very many occasions when writing to mirc.ini anyway, since the mirc.ini contents are loaded into memory and cached on load and only written back out on exit or an explicit call to /flushini mirc.ini, from what I understand. This would solve the high chance of mirc.ini corruption without having to fflush.