network drive path converting to UNC path.

[kleinstein]

well...

i want to take a folder from user and convert it to UNC path under windows 7.
(my environment is: NSIS Unicode version 2.46.5, Windows 7 Pro)

so i searched plugins, googled, and saw also wiki site.



what i found is this: Get Universal Name

http://nsis.sourceforge.net/Get_Universal_Name

and my code is really simple like example:

code:


Push "Z:\Austausch\skj\skj_rlm_gis.lic"

Call get_universal_name

Pop $0 ; sould be = "\\zeus\data\Austausch\skj\skj_rlm_gis.lic"

But it does not work. it give me always Error 1200 (this means, ERROR_BAD_DEVICE : The string pointed to by lpLocalPath is invalid. But the input path is Valid!!)



is there any other way to convert to UNC Path?

[Anders]

Change WNetGetUniversalNameA to WNetGetUniversalName

[kleinstein]

it does not work.

[Anders]

Try WNetGetUniversalNameW then, the A/W detection is not the same in every version of the system plugin.

[kleinstein]

Try WNetGetUniversalNameW then, the A/W detection is not the same in every version of the system plugin.

it does not work either.

WNetGetUniversalNameA
WNetGetUniversalName
WNetGetUniversalNameW

these 3 makes no changes.. i get no unc path from them..

[Anders]

There was already a thread for this function (linked on the wiki page), why did you not ask there?

Anyway, I updated the wiki page and it should now support NSIS 2.4x (Ansi) and NSIS 3 (Unicode & Ansi). This does not mean that the Unicode fork you are using will work, if it does not then you should ask why at the scracthpaper.com forum.

If you want to always force Unicode you could try:

Function get_universal_name_WIDE
Exch $0
Push $1
Push $2
System::Call '*(i,&w${NSIS_MAX_STRLEN} "")i.r2'
!define /math get_universal_name_UNIWSIZE 2 * ${NSIS_MAX_STRLEN}
System::Call 'mpr::WNetGetUniversalNameW(wr0,i1,i$2,*i${get_universal_name_UNIWSIZE})i.r1'
!undef get_universal_name_UNIWSIZE
IntCmpU 0 $1 0 retlocal retlocal
System::Call "*$2(w.r0)"
retlocal:
System::Free $2
Pop $2
Pop $1
Exch $0
FunctionEnd
...
push "x:\demo.mp3"
call get_universal_name_WIDE
pop $9

[kleinstein]

There was already a thread for this function (linked on the wiki page), why did you not ask there?

Anyway, I updated the wiki page and it should now support NSIS 2.4x (Ansi) and NSIS 3 (Unicode & Ansi). This does not mean that the Unicode fork you are using will work, if it does not then you should ask why at the scracthpaper.com forum.

If you want to always force Unicode you could try:

Sorry, but it does not work either...


But, Many thanks to you for your help.
My goal was not fixing Get_Universal_Name function.
I just want to convert the mapped drive path to UNC path. That's all.

so i made the title of this thread for this purpose.

Get_Universal_Name function was just the one, that i found out for this goal.

Maybe there is already other solution, or?

Anyways, thank you again.

[kleinstein]

Sorry, but it does not work either...


But, Many thanks to you for your help.
My goal was not fixing Get_Universal_Name function.
I just want to convert the mapped drive path to UNC path. That's all.

so i made the title of this thread for this purpose.

Get_Universal_Name function was just the one, that i found out for this goal.

Maybe there is already other solution, or?

Anyways, thank you again.

I must say, i am sorry for this false alarm.

My installer need to get the administration right.

And after installer start, all network drive are not yet connected in installer file selection dialog! i don't know why..

but if i open an file explorer at the same time, then i can see all my network drives are good connected already.

i think this is some of windows feature, that the network drives are not always connected. after click on this network drives in installer file dialog, it works very fine.

so.. i should now figure it out, how i can connect the network drive in my installer script in background.

Sorry for all this.. thank you!

[Anders]

Network drive mappings (and the logon passwords if any?) don't survive UAC elevation because the new elevated process uses a different process token.

You can find more information about this issue by searching this forum or look at some MSDN blogs from the early Vista days...