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

Comments

Projects
None yet
3 participants
@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

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Dec 8, 2017

Member

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
Member

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

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Jan 12, 2018

Member

Closing this due to no feedback

Member

polyvertex commented Jan 12, 2018

Closing this due to no feedback

@polyvertex polyvertex closed this Jan 12, 2018

@horinan

This comment has been minimized.

Show comment
Hide comment
@horinan

horinan 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

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

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Mar 9, 2018

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@horinan

horinan 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

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

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Mar 12, 2018

Member

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)

Member

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

This comment has been minimized.

Show comment
Hide comment
@horinan

horinan 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

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

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Mar 13, 2018

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@horinan

horinan 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

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

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Mar 14, 2018

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@horinan

horinan 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

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

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Mar 14, 2018

Member

Thanks for confirming

Member

polyvertex commented Mar 14, 2018

Thanks for confirming

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

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Sep 13, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@horinan

horinan 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

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