mIRC 6.1 "global-bug" still there - mIRC Discussion Forums

Command: /mkdir global
returns: * /mkdir: unable to create 'C:\mIRC\global'

This bug was also in 6.03.

But only in Windows 2000 SP4
(on windows xp - no error message)

Description: I use the command above, mIRC create the folder but return this error message.

maybe take a look at https://forums.mirc.com/showflat.php?Cat=...=true#Post11868
where i posted it the first time.

So if you reply to this post please write down your windows version (with SP and such things)

/mkdir global <- creates the folder c:\internet\mirc\global\ without a problem.

I suspect you have a file named 'global' with no extension, in your $mircdir.
As you may know, you cannot have like-named files and folders in the same directory.

- Raccoon

No, i use a new installed mIRC (6.1 but also tried other versions 6.03) without any scripts, dll or other files just a default installation. can your please write donw which winodws version you use

Win 98SE
Fat32
mIRC 6.1

The behaviour seems intermittent but I've made a change that should fix it in the next version.

Quote:

The behaviour seems intermittent but I've made a change that should fix it in the next version.

For what it's worth - this bug is still there in 6.16, running Windows XP Pro.

I'm using mIRC to write my own custom backup solution (nutty? maybe - but I tried everything else free + bundled out there and suffice to say that I think the authors are nuts.), and it throws an error on:
* /mkdir: unable to create 'f:\backup\Program Files\Common Files\Microsoft Shared\Themes\global'

However, the folder does get created. My work-around, currently, is to detect whether the folder that is trying to get created ends in 'global', and if it does, rename it 'global$ID$', where ID is a random string - making it unlikely that there was an original folder called 'global$ID$".

This is an odd bug, though - is there an internal variable called 'global' that's causing this?

Funny... here's another one... "SynTP"

* /mkdir: unable to create 'f:\backup\Program Files\Synaptics\SynTP'

Dir gets created, but spawns that error message.

I haven't the foggiest why that would be happening - "Syn" works, "SynTPz" works.

I could understand* if 'global' was an internal variable, but why would 'syntp' be one?
(* though internal variables should never be evaluated in the mkdir string?)

Thought I posted this reply already.. anyway.. two more: "pipe" and "ndis" are also dir names that throw an error in mkdir, but get created just fine

You can use this utility to get a list of names that mIRC considers to be reserved for file/dir names (run it from a DOS window).

Aha... thanks a lot

Well that sure is annoying. I've coded 'around' the issue in the mean time by starting a timer that restarts the process (a /copy error apparently doesn't go to the :error handler.. bah) and warns me that there was a problem. I guess I can dump the copying of potentially problematic files to a .bat file, then /run that, then check the results to see if there were any -actually- problematic files.

Or I can pick up VB/VC++ and learn to code with those. Shame, though, mIRC technically has everything I'd need it to do (file access with properties, crc/md5, display output, connectivity, etc.). I guess I'll keep trying for a bit, but if hitting more non-trivial snags (that consecutive spaces bit is another) I'm not going to waste more time on it.

Yeah, hopefully the restriction will be lifted in the next mIRC version. We're way past the old /con/con Windows bugs, and even then I seriously doubt that this check has ever been effective against anything..

It really is quite silly...

Say you have a file "c:\somedir\global.txt"...

$isfile(c:\somedir\global.txt)
returns
$false

But you can still find the file using $findfile, so...

Code:

alias fileExists {
  if ($findfile($nofile($1-),$nopath($1-),0,1) == 1) { return $true }
  else { return $false }
}

$fileExists(c:\somedir\global.txt)
returns
$true

So obviously if it was intended as a security feature, it's one that is rather easy to bypass.

For the curious as to how much slower that function is, here's some results for 10,000 calls..
On an existing file:
$isfile: 2.263s
$fileExists: 1.502s

On an existing 'reserved' file
$isfile: 1.052s
$fileExists: 1.522s

On a non-existing file:
$isfile: 2.413s
$fileExists: 1.382s

Funny, no? It's faster in all but 1 case - and in that case, $isfile returns bogus data anyway so who cares how fast it is %) If needed in a loop over dirs, $nofile can be precalced, and it's even faster. Silly.