|
Joined: Aug 2006
Posts: 11
Pikka bird
|
OP
Pikka bird
Joined: Aug 2006
Posts: 11 |
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\
Last edited by daGroove; 04/08/06 11:39 PM.
sorry for my english
|
|
|
|
Joined: Apr 2004
Posts: 218
Fjord artisan
|
Fjord artisan
Joined: Apr 2004
Posts: 218 |
I'm unable to reproduce this, but this doesn't eliminate it as an bug. =x
Live to Dream & Dream for Life
|
|
|
|
Joined: Jul 2006
Posts: 7
Nutrimatic drinks dispenser
|
Nutrimatic drinks dispenser
Joined: Jul 2006
Posts: 7 |
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
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.
|
|
|
|
Joined: Aug 2006
Posts: 11
Pikka bird
|
OP
Pikka bird
Joined: Aug 2006
Posts: 11 |
but mirc6.17 always return longfilename...
sorry for my english
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
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.
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
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\
|
|
|
|
Joined: Aug 2006
Posts: 11
Pikka bird
|
OP
Pikka bird
Joined: Aug 2006
Posts: 11 |
my target is always long path.. and mirc6.17 returns long path... but mirc6.2 sometines short, sometimes long...
sorry for my english
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
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.
|
|
|
|
Joined: Aug 2006
Posts: 11
Pikka bird
|
OP
Pikka bird
Joined: Aug 2006
Posts: 11 |
there is nothing different, but is ok...
sorry for my english
|
|
|
|
Joined: Dec 2002
Posts: 5,426
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,426 |
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.
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
Could you not just put the return value through $longfn() (or whatever you use internally) so it's always long?
|
|
|
|
Joined: Dec 2002
Posts: 5,426
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,426 |
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.
|
|
|
|
Joined: Aug 2006
Posts: 26
Ameglian cow
|
Ameglian cow
Joined: Aug 2006
Posts: 26 |
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).
|
|
|
|
Joined: Jan 2003
Posts: 1,063
Hoopy frood
|
Hoopy frood
Joined: Jan 2003
Posts: 1,063 |
C:\Program Files\
is really C:\Progra~\
actually, it would be Progra~1 ;-] it's always numbered, also the first one.
If it ain't broken, don't fix it!
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
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.
|
|
|
|
Joined: Jan 2004
Posts: 2,127
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 2,127 |
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)
|
|
|
|
Joined: Nov 2003
Posts: 50
Babel fish
|
Babel fish
Joined: Nov 2003
Posts: 50 |
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.
|
|
|
|
|