Originally Posted By: Khaled
Thanks for looking into this, however this behaviour is by design. There are some contexts where a DeleteFile() is queued [..]

You're missing the point. mIRC should not be calling DeleteFile() at all here. It should atomically replace the existing file with the new file, and there are API calls to do that. mIRC is currently not using them. mIRC should be using them. If for some reason these API calls fail, mIRC could still fall back to the old, less safe behavior.

Originally Posted By: Khaled
the only real way to track this down would be to find a way to reproduce it by inducing a BSOD, since that seems to be the specific situation which causes it and which I have not been able to reproduce.

No, that is simply not true. Robustness against system crashes starts with robustness against application crashes. The best thing that an application can do to protect itself from problems resulting from a system crash, is to make sure that at all times, the file system contains a state from which the application can recover. In mIRC's case, that means that at the very least there should always be a valid mirc.ini in the file system. This may not be sufficient to prevent all cases of corruption, but it is a necessary condition.

Right now, mIRC is playing fast and loose with mirc.ini, which may result in its effective loss.

You could ignore the clear problem in front of you and try to figure out exactly what is going on with BSODs, or you could let mIRC do the right thing right now and see if that doesn't already resolve the problem in the majority of the (many, many) current cases. This really shouldn't be a hard decision.


Saturn, QuakeNet staff