Forums Scripts & Popups mIRC's reaction to a /write failure

I don't believe I'm dealing with an mIRC bug here. I might be mistaken. I have "searched" for similar instances in the board and can't find one. I have a script that creates a special kind of logfile for what happens in a room.

The way it writes the log, quite simply, is repeated /write commands to a log file. This works about 99.98% of the time.

Every now and then, the write will fail. I will get this message:

/write: error updating 'C:\Documents and Settings\MegaZeroX\My Documents\StarStorm RED\S-Logs\» KAMPUNG_DALnet_12292004.txt' (line 386, Sentinel Procedures.ini)

I know what you're all thinking -- it's a scripting error. I wish. Having analyzed and re-analyzed everything that is going into that /write command, I am quite sure that 1) the write file exists and 2) intended things are being sent to the /write command line.

When an error happens, the target file disappears and is replaced -- in the main mIRC folder -- with a file named mIRC243.tm_ or mIRC479.tm_, something along those lines. It would seem to represent a temporary file when a write command has failed.

The fact that the target file disappears is the reason I'm emphasizing that I know with 100% certainty that it existed as and where it should immediately prior to the /write.

Which leaves one conclusion: Windows simply didn't manage to write as requested. Now, mIRC's reaction (again, after analyzing and re-analyzing over a period of days) would seem to be to MOVE the target file to the main mIRC directory and rename it "mIRCxx.tm_"

I can probably write a DLL file that will circumvent the entire issue and handle the file-writing itself. But I'm just wondering if anyone has any idea how else this issue might be avoided. Khaled might just be the only person who knows the answer to this question.

For heavy writing tasks it's recommended to use the new file handling commands (/help /fopen). Also, it's possible to handle errors like the one you encountered (/help error handling). Both features have been improved since they were added so it's probably best to test them on the most recent version of mIRC (6.16).

As online said use the new fopen fwrite fclose as this saves on the huge levels of disk read and writing a /write does, see the problem isnt mirc moves the original file, but rasther its making a copy of the original with the changes in it, then (i assume) it deletes the original and renames/moves the copy to the location of the original, would appear that you maybe getting some type of error in mirc between two internal steps of the /write command, the build a new file & the rename/move parts.

Im wondering if u have another application accessing the file also and it maybe a problem with file access rights etc.

Yeah, thanks guys. From what I can tell, the new code works great.

P.S. Yeah, I agree it's something going on with the internals of /write.