Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
to-taka opened this issue Dec 8, 2017 · 14 comments
Closed

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

to-taka opened this issue Dec 8, 2017 · 14 comments

Comments

@to-taka
Copy link

@to-taka to-taka commented Dec 8, 2017

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:

image

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
Copy link
Member

@polyvertex polyvertex commented Dec 8, 2017

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
Copy link
Member

@polyvertex polyvertex commented Jan 12, 2018

Closing this due to no feedback

@polyvertex polyvertex closed this Jan 12, 2018
@horinan
Copy link

@horinan horinan commented Mar 8, 2018

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
Copy link
Member

@polyvertex polyvertex commented Mar 9, 2018

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
Copy link

@horinan horinan commented Mar 11, 2018

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
Copy link
Member

@polyvertex polyvertex commented Mar 12, 2018

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
Copy link

@horinan horinan commented Mar 12, 2018

Hi,

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

image

Regards,
taka-t

@polyvertex
Copy link
Member

@polyvertex polyvertex commented Mar 13, 2018

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
Copy link

@horinan horinan commented Mar 13, 2018

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
Copy link
Member

@polyvertex polyvertex commented Mar 14, 2018

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.

@polyvertex polyvertex reopened this Mar 14, 2018
@horinan
Copy link

@horinan horinan commented Mar 14, 2018

Sorry for my ambiguity, and the UNC path returned from the sample code show the shared folder path(\?\UNC\xxx.xxx.xxx.xxx.local\taka-t...), not the mounted drive.

Yes, KP works perfectly on my local drive with Japanese OS.

Regards,
taka-t

@polyvertex
Copy link
Member

@polyvertex polyvertex commented Mar 14, 2018

Thanks for confirming

@polyvertex polyvertex changed the title Keypirinha portable does not work on Microsoft VDI environment Run from a shared folder or mounted drive (UNC path) Sep 13, 2018
@polyvertex
Copy link
Member

@polyvertex polyvertex commented Sep 13, 2018

This should be fixed in v2.19, please give it a try!

@polyvertex polyvertex closed this Sep 13, 2018
@horinan
Copy link

@horinan horinan commented Sep 13, 2018

Hi @polyvertex ,

It works on my VDI env!
I really appreciate your handling. I'll use the Keypirinha forever :)

Regards,
Taka-t

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.