mIRC Homepage
Posted By: daGroove $mircdir bug ? - 04/08/06 11:31 PM
hello,

sometimes $mircdir returns full path and sometimes it returns shortfilename?


echo -a $mircdir

returns:
C:\Programme\[mIRC]\-=[mIRC-Work]=-\=mIRC=LEER\


after restart:

echo -a $mircdir

returns:
C:\PROGRA~1\_MIRC_~1\-__MIR~1\_MIRC_~1\
Posted By: PhantasyX Re: $mircdir bug ? - 05/08/06 02:04 AM
I'm unable to reproduce this, but this doesn't eliminate it as an bug. =x
Posted By: sbsb Re: $mircdir bug ? - 05/08/06 02:25 AM
Confirmed
Posted By: DaveC Re: $mircdir bug ? - 05/08/06 07:53 AM
Dont ask me how, but i have seen this in all types of windows applications, under some set of conditions the path of executing applications (and other such paths) have been shown as short filenames, I beleive this is a OS problem rather than mircs. I think mirc is likely just pulling its $mircdir value from the os at some point, and for what ever reason it is being handed to mirc as a short filename.

A simple example, assuming your the Administrator (if not substitute your username in)

Copy MIRC.EXE into C:\Documents and Settings\Administrator

Do a dos drop into C:\Documents and Settings\Administrator (start>run>cmd>ok)

Then in the dos drop at "C:\Documents and Settings\Administrator>" type in MIRC.EXE
Then in mirc type //echo -a $mircdir
C:\Documents and Settings\Administrator\

Exit mirc, and back in the dos drop type EDIT, then alt-f and x to exit it
Dos drop becomes "C:\DOCUME~1\ADMINI~1>"

Then in the dos drop at "C:\DOCUME~1\ADMINI~1>" type in MIRC.EXE
Then in mirc type //echo -a $mircdir
C:\DOCUME~1\ADMINI~1\

* see mirc is just returning the the mirc dir as it is defined by the OS
* solution is $+($longfn($mircdir),\) this produces the longfilename (and adds the ending \) nop matter if it was long or short.
Posted By: daGroove Re: $mircdir bug ? - 05/08/06 07:24 PM
but mirc6.17 always return longfilename...
Posted By: maroon Re: $mircdir bug ? - 05/08/06 08:35 PM
Check the icon/pif/whatever you use to start mIRC, to see whether your target is running C:\PROGRA~1\_MIRC_~1\-__MIR~1\_MIRC_~1\mirc.exe - and if so, change the path\target.
Posted By: DaveC Re: $mircdir bug ? - 06/08/06 06:34 AM
Quote:
but mirc6.17 always return longfilename...


I hate how people just say "but" and dont even check in anyway what there saying....

Becuase you are incorrect. mirc6.17 might have for the times you ran it always returned long file paths, but it does NOT always return long file paths.

C:\Program Files\mIRC617>mirc.exe & //echo -a $mircdir
C:\Program Files\mIRC617\

C:\PROGRA~1\mIRC617>mirc.exe & //echo -a $mircdir
C:\PROGRA~1\mIRC617\
Posted By: daGroove Re: $mircdir bug ? - 06/08/06 04:25 PM
my target is always long path.. and mirc6.17 returns long path...
but mirc6.2 sometines short, sometimes long...
Posted By: DaveC Re: $mircdir bug ? - 06/08/06 05:04 PM
im not going to explain it again, I already told you that it sure looks like mirc just reports what the OS tells it, something on your system is different from one install to the other.
Posted By: daGroove Re: $mircdir bug ? - 06/08/06 09:43 PM
there is nothing different, but is ok...
Posted By: Khaled Re: $mircdir bug ? - 07/08/06 01:26 PM
The method to retrieve the path is the same in mIRC v6.2 and v6.17, there has been no change to the method as far as I can tell.

I was able to reproduce the issue using the method described by DaveC, which seems to indicate that mIRC is returning the path reported by the OS.
Posted By: hixxy Re: $mircdir bug ? - 07/08/06 01:49 PM
Could you not just put the return value through $longfn() (or whatever you use internally) so it's always long?
Posted By: Khaled Re: $mircdir bug ? - 07/08/06 02:30 PM
Yes but then I wouldn't be returning the same value that the OS is returning, and the OS may be returning that value for a reason.

Also, for consistency, I would need to do this for every path value in all routines in mIRC, which may not be possible since a script (or routine in mIRC) may purposefully use $shortfn() and pass that value to path-processing routines.
Posted By: Dromedary Re: $mircdir bug ? - 08/08/06 04:26 PM
i'm nearly positive this shortening is caused by the fat32 filesystem. in NTFS and such it will not shorten (this is probably why in 6.17 it never shortened for the person who reported that).

there was an extension to the fat32 file system added around windows98 i think that allowed the full path data to be stored, so full path data is stored, but short file names are still used internally. for example

C:\Program Files\

is really C:\Progra~\

and if there's another like C:\Programs

it will be C:\Progr~1\

i am not sure how fat32's new extension stores the full path data, but i know it's stored somewhere... maybe because of this there is a way to more easily. always return the full path. the full path in windows should always work just so long as fat32 has those extensions (win98 and higher i would think).
Posted By: Doqnach Re: $mircdir bug ? - 10/08/06 05:51 PM
Quote:

C:\Program Files\

is really C:\Progra~\


actually, it would be Progra~1 ;-] it's always numbered, also the first one.
Posted By: DaveC Re: $mircdir bug ? - 10/08/06 11:35 PM
FAT32 is not the cause, The 32 is the size (in bits) of the fat table entries in a fat formated partition. Also my examples were carried out under a NTFS drive., So it Well shorten

FYI: On a FAT drive the long filename extentions added to the 8.3 filesystem directory structure added with win95 are stored in the directroy structure precedding the 8.3 filename which is normally XXXXXX~N.EXT of the LFN, each 32 byte directory entery holds just 13 charaters of the LFN, they are staggered backwards with the 32 bytes directly precedding the SFN containing the first 13 characters of the LFN, then 32 bytes before that having the 2nd 13 etc etc, the backward stored logic of them would imply that the true filename is infact the SFN with the LFN being an additional name also given to the file, this would hold with the fact a true dos only session can still read the files using there SFN, but well not copy/move the LFN should the file be copy/moved.
Posted By: maroon Re: $mircdir bug ? - 12/08/06 01:02 AM
You can avoid many of the problems that the changing $mircdir can cause, by referring to locations indirectly, instead of by the complete c:\path\filename.

Instead of using $mircdirSubFolder\filename.txt to refer to a filename, you can use instead SubFolder\filename.txt which works regardless what the $mircdir is. You can easily strip the mircdir out with $remove($mircdirSubFolder\filename.txt,$mircdir)
Posted By: x64 Re: $mircdir bug ? - 23/08/06 10:49 PM
The output of the function depends on the "working directory" that mirc was started in. It's possible that when you installed 6.2, this updated/changed the shortcuts that point to mIRC. Personally, I've never had this problem, because I have no reason to make my mIRC directory use more than 8 characters.
© mIRC Discussion Forums