I should point out that never in my 20+ years of using Windows have I run into another application (besides mIRC) that has corrupted a configuration file during a system reset / crash / etc. -- on the other hand, I've had mIRC corrupt the ini file on at least 5+ known occasions (the most recent a few weeks ago.

Although this is technically not specific in theory to mIRC, it is very specific in practice to mIRC's implementation alone. This is is really not common in other applications (the linked Google search targets generic data loss, most likely for unsaved work, which is very different from this specific use case. You'll note that none of those search results actually refer to corrupted applications, just user data, and many of those results are specific to corruption at the hardware level), and if other applications did this, they should expect to receive bug reports about it and eventually fix the root cause. That is to say, mIRC could be doing more to at least mitigate this issue if not outright resolve it. The sad part here is that all the hand-waving about this being a "common Windows issue" completely glosses over how easy it is to mitigate/fix the issue altogether, regardless of how innate it is to the OS (though I disagree with the premise).

Although I don't know the exact technique mIRC uses, I can make educated guesses that part of the problem comes from the likelihood that mIRC is constantly opening mirc.ini for writing, rewriting the entire ini file in one shot (i.e., opening the file in truncate mode) and then holding on the handle for a "while" without flushing written contents to disk. If that's the case, a simple fsync() (or FlushFileBuffers() in WINAPI) would mostly solve the problem in most cases except where Windows crashes between writing and flushing, which should be exceedingly rare. If mIRC flushes as soon as it writes, this should never be a problem. If mIRC is not already doing this, it should. File contents are never corrupted if mIRC is only opening a file for reading (or not modifying the buffer). Again, I am probably wrong about some of the details, but I do know that this has never been an issue for any other program I've used that writes configuration (namely, all of them).

I personally think this issue deserves more attention and legitimacy as a real problem. Users in various support channels complain about this fairly often-- often enough that it should be resolved or at least mitigated by changing mIRC's file handling routines to be more robust.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"