I searched for mentions of this bug, and the closest I could find are references to the /write bug in 6.1 thru 6.12 that has been fixed, but that is not what I'm describing here.
I finally stumbled across clues for a /write bug that's been bugging me across numerous mIRC versions, including the current one. It's difficult to trace the bug because I can't induced it to occur on demand, nor have I noticed any conditions that make it more likely to happen. It happens (luckily rarely) when using the -l# switch to either write to a specific line number, or when using the -dl# switch to delete a line. I've had it happen several times within a few hours, and then not happen again for several years. I know people who seem to have a file disappear every few weeks, and others who've never had it happen to them.
Someone was having the problem pretty frequently, so after trying several things, including installing mIRC on a completely different physical disk drive, they ran FileMonitor to see what's happening, and gave me their logfile. It showed there were no other programs writing to disk at the time it happened. Regardless whether the file being written to is located in the mIRC folder or elsewhere, it appears that mIRC creates a temporary file in $mircdir named mircN.tm_ - where N is a number that is sequentially increased, without leading zeroes, each time mIRC writes to a temp file. The process of updating file.dat appears to boil down to:
A. Create mirc123456.tm_
B. Alternate between reading file.dat in 4kb chunks, and writing the updated file contents to mirc123456.tm_ for the entire file.
C. Delete file.dat
D. rename mirc123456.tm_ as file.dat
The problem happened when FileMonitor reported that the attempt to delete file.dat was "DELETE PEND", instead of the normal "SUCCESS". This caused the Step#D rename of mirc123456.tm_ to fail because the destination filename already existed. mIRC appears to be assuming that file.dat is being successfully deleted, even when it's not (yet). I'm assuming that the temp filename indicates the temp file is being created by mIRC instead of being assigned by the O/S. The file.dat appears to disappear through no scripting error, because the DELETE PEND eventually succeeds. I've seen this problem happening under several mIRC versions, as well as several O/S's besides XP.
One way to avoid this problem could be to instead:
A. Rename file.dat as mirc123456.tm_
B. Create file.dat again
C. Use mirc123456.tm_ as read-input as it writes the updated file to file.dat.
D. Delete mirc123456.tm_
This way, when the "delete pending" happens, file.dat will have the updated info, and the .tm_ file will simply take a few milliseconds longer to be deleted and disappear. Of course, this assumes that the O/S would never fail Step#A with a rename-pending.
Previously, I had suspected that this is how file.dat occasionally disappears, but I discounted it since I wasn't finding $mircdir littered with stray mirc*.tm_ files.
However, the reason there are not numerous mirc*.tm_ files which someone can use to recover their missing file.dat is because mIRC tramples over existing mirc*.tm_ filenames. To demonstrate this, open a new mIRC without scripts, so that the *.tm_ files start being named as mirc1.tm_ then run:
//var %i 100 | while (%i) { write $+(mirc,%i,.tm_) test %i | dec %i }
This creates mirc1.tm_ through mirc100.tm_ - and as you repeat:
//write -l1 test.txt test | echo -a $findfile($mircdir,*.tm_,0)
you will see the mirc*.tm_ files disappearing.
You can find your missing disk file by hunting for *.tm_ files in $mircdir - as long as you search before restarting mIRC and the .tm_ filenames get re-used. Any mirc*.tm_ files you find would have the date/timestamp of the last write, and since the filenames are used sequentially, the sooner you discover the problem, the better chance you have of recovering the original file. The higher the mircNNNN.tm_ number, the older the file will be.
