Are there any plans to fix this old bug? Not being able to manipulate some perfectly valid files it looks like I'm going to have to move some script functionality to a .dll or .exe, something I'd really rather avoid.

That's not technically a bug, per se. Windows considers certain names to be devices and so mIRC does as well. Granted, that's pretty much an outdated method of determining devices, but I don't believe Windows has chosen to drop it even in Vista.

In any case, you're looking at a very small number of names that cannot be used and there's absolutely no reason why you *have* to use them, so just change to something else instead.

Sat's answer in the OP's referenced thread was indeed interesting though. Just because mIRC uses a Windows API to declare that file as reserved does not necessarily mean mIRC is properly using that API, or being a bit too reliant on Windows' results when they may not be fully accurate or used in the right context.

The idea that I should just use other names assumes that I have some control over the filenames my script has to manipulate. A reasonable assumption for most cases but of course it doesn't hold true for all scripts. Trust me, I would not bother duplicating script functionality in a DLL if simply using other filenames was an option here..

What exactally are you trying to do, and what file names are you trying to use?

The initial bug report that I received was about deleting a file named pipe.pm but the problem also affects other mirc commands and identifiers.

/remove x:\path\pipe.pm - fails with "/remove: no such file"
/remove x:\path\pipe2.pm - ok

You could use a cmd batch file to perform tasks on those restricted filenames. Just write a batch file from within your script, execute it, and then remove it. I don't know if there is any way to tell if it was successful or not.

-genius_at_work

Whilst Windows in general handles this fine, mIRC it's self cannot.

It appears as if mIRC has an internal list of reserved words, probably introduced during the '95 days, that has dis-allowed filenames. Does anybody remember the old send-a-file-called-com1 issue of old?

$read(), /remove, /copy and others have issues with it (copy copies it to another name, but fails to remove the old instance).

/fopen et al commands seem to not have this issue.

There's no mention of reserved names in the versions.txt history however.

I don't know exactly what happens within mIRC's coding (obviously), but Khaled stated in the referenced thread, basically, that mIRC asks windows and windows says yes or no. Maybe the method being used is outdated, but mIRC is designed to work with outdated versions of windows (I believe). If Khaled told us what method he used (the windows command that is called), maybe others here could suggest a different method.

-genius_at_work

He stated that the funcion he's calling returns whether the file is a 'device'.

As these file names could potentially be devices, he's discarding them as a possible file name..

So yeah, it's possible the routine he's using is outdated.. But then there's the whole backward compatability thing..

And, of course, Windows itself is the one stating it's a device... even in newer Windows versions, so it's partle Windows' fault.

Don't be silly. Windows does not state that all device names are invalid file names. Some are, but most are not. mIRC assumes that all of them are, so only mIRC is at fault here.

Well, according to Khaled...



So, mIRC is asking Windows and Windows is replying. If Windows *didn't* say that those were devices, then mIRC wouldn't consider them invalid filenames. As mentioned, the method used to ask Windows may be outdated with newer Windows versions, but with backward compatibility, there may not be an easy way to change how it asks Windows about this. Of course, mIRC could just allow writing to those no matter what and let Windows complain about it, but I don't know if that's any better either. I think a better idea would just be to have the error that mIRC generates explain that it's a device name so people actually know what the problem is (not sure if it does or not).

Again, not all (MS-DOS) device names are invalid (Windows) file names. You can't blame Windows for providing information that is used improperly by mIRC. Remember that mIRC is not an MS-DOS application, and never was.

What mIRC should do instead is test for a small subset of hardcoded device names - see the "reserved device names" list at Microsoft's own advice on naming files.