Run from a shared folder or mounted drive (UNC path)

[to-taka]

Hi,

I'm using virtual desktop environment called VDI at my office, that strictly limits user control over their desktop use.

(VDI)
https://www.microsoft.com/en-us/cloud-platform/desktop-virtualization

I put the 64bit portable of Keypirinha on the VDI desktop and tried it, but keypirinha.exe outputs following error when I double click it:

those binaries that I tried perfectly works on my ordinary laptop, so i think the cause is not in the corrupted files of Keypirinha, but my special VDI environment.

So, I want to know the fundamental cause of the message to do some workarounds. Could you advise any ideas to know the cause?

Regards,

[polyvertex]

This message pops up when the embedded Python interpreter fails to initialize, which usually happens when some files/dlls are missing in a normal environment.

I'm not familiar with how VDI works under the hood but the init step that fails and leads to this message only involves a single function call to the Python interpreter, which does not provide precise error code/message when something goes wrong in this case. Hence the vague nature of this message.

Since file redirection did not have time to take place (i.e. Python to Keypirinha), Keypirinha's log file may not be of any help neither so perhaps you can try Keypirinha's SDK and see if the Python interpreter prints something useful on a console:

• Download the SDK
• Extract and open a command console at its root
• Type cmd\kpy
• This will launch the interpreter, check what's printed

[polyvertex]

Closing this due to no feedback

[horinan]

Hi @polyvertex,

I checked the output of interpreter, but it's the same as that of normal non-VDI machine.

Just let me ask a question.
Does the Keypirinha portable works when the binaries are located on network drive folders?
I found that Keypirinha output the same errors even on the normal machine when they are located on the network drive. And, our VDI environment seems to mount network folders as user's document folder on its login.

Regards,
Taka-t

[polyvertex]

Due to a limitation from the embedded Python interpreter, Keypirinha should be able to run from a network storage only if the network folder is mounted as a drive first (itself or its parent). See #190.

Can you do that from your VDI environment?

[horinan]

Hi,

Thanks for your advice. I created new portable.ini and set portable_dir using Drive character.
But as the following logs, i can not prevent official packages seeing UNC path.
Any ideas are appreciated.

• I mounted the Keypirinha folder as M drive using 'net use' command.

---

2018-03-12 08:03:06.352 [i] Official packages: \?\UNC\xxx.xxx.xxx.xxx\taka-t\Keypirinha\default\Packages
2018-03-12 08:03:06.430 [i] Profile dir: M:\Keypirinha\portable\Profile
2018-03-12 08:03:06.508 [i] Local dir: M:\Keypirinha\portable\Local

Regards,
Taka-t

[polyvertex]

Mmmh for the purpose of this test, you should not need to create the portable.ini file... Just to clarify, did you launch KP from the mounted drive during that very test? I.e. by double-clicking on the keypirinha.exe located under the mounted drive (as opposed to the shared folder)

[horinan]

Hi,

I tried as below image. My understanding is correct? I'm just worried that I misunderstand what you mention as 'mounted drive'.

Regards,
taka-t

[polyvertex]

Yes, your test seems correct.

In the light of your test, there might be a way to solve this but it's nothing you can do unfortunately and you will have to wait for a next release of Keypirinha.

Thank you for taking the time to perform these tests.

Technical details: Keypirinha calls the GetFinalPathNameByHandle Windows function at launch time to locate itself in a reliable way. This a compulsory step for KP. But I suspect that despite the folder being mounted as a drive, GetFinalPathNameByHandle still resolves the path of the folder to its original UNC path, which Python does not seem to support.

[horinan]

Hi @polyvertex ,

Thanks for your input.
I checked the funcion's reference below:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364962(v=vs.85).aspx

And create the sample source just modifying the parameter as following,
dwRet = GetFinalPathNameByHandleW(hFile, Path, BUFSIZE, VOLUME_NAME_DOS);

then run it on my environment specifying files on mounted drive, but it always returns UNC path.
I would highly appreciate if you can tackle the issue and please let me know if further tests are needed on my side.

Regards,
Taka-t

[polyvertex]

Yes GetFinalPathNameByHandle always returns UNC paths with that flag (e.g. \\?\C:\Folder\File.txt) but the question is: does it return the UNC path to the mounted drive (e.g. \\?\M:\Keypirinha\...) or to the shared folder (e.g. \\?\UNC\xxx.xxx.xxx.xxx\taka-t\Keypirinha\...)?

Also, since you seem to run a Japanese version of the OS, it might be that KP doesn't fully support the localized path separator (¥) at some key steps, since some manual path parsing is involved internally in many places. According to all the documentation and feedback I've read on the subject when I started developing KP, it shouldn't be an issue but no test were performed with KP to confirm/refute that. However, since KP seems to run properly on your OS when not running from a network location, I would tend to stick to my first guess that it's just about GetFinalPathNameByHandle being too good at its job.