Bug 419294

Summary: Open with does not work with collection on network shares (on Windows)
Product: [Applications] digikam Reporter: Benny <jff2k>
Component: Usability-OpenWithAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, metzpinguin
Priority: NOR    
Version First Reported In: 7.0.0   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed In: 7.0.0
Sentry Crash Report:
Attachments: Error message with context menu open with (german Windows)
Configuration - Collections on Network Shares
This file does not have an app associated with it for performing this action.
Tested on a third device with clean install
Windows Dialog for Unknown Filetype
Recoreded with Problem Step Recorder
Recoreded with Problem Step Recorder (V2)
Recoreded with Problem Step Recorder (V3)
Screenshots from legacy windows versions

Description Benny 2020-03-27 14:41:07 UTC
Created attachment 127043 [details]
Error message with context menu open with (german Windows)

SUMMARY
I've configured my album via "collections on network shares" to a \\smb\path. When using the context menu "open with" I'm getting an error from the operating system "//smb/path/... could not be found."

STEPS TO REPRODUCE
1. Set up an album in "collections on Network Shares"
2. navigate to a picure
3. right click and select "Open With"

OBSERVED RESULT
Error message ""//smb/path/..." could not be found. Make sure you typed the name correctly, and then try again." 
Maybe it's the way how the network path is sent to the operating system? //smb/path instead of \\smb\path?

EXPECTED RESULT
Open the "Open with" dialog

SOFTWARE/OS VERSIONS
Windows: Window 10 1909

ADDITIONAL INFORMATION
Same behavior in digiKam 6.4.0 and 7.0.0-beta-2.
Comment 1 Maik Qualmann 2020-03-27 14:49:51 UTC
DigiKam does not support network paths because some of the libraries used by digiKam do not. You need to assign a drive letter to your network path.

Maik
Comment 2 Benny 2020-03-28 15:32:50 UTC
Hi Maik, thank you for your quick reply. 

I didn't get any error message in digiKam when I added the network share by UNC-path. And I've found no hint in the digiKam-documentation, that it's not supported to use UNC-paths? Can you tell me which part of digiKam does not support UNC-paths (beside "Open With")?

It's working perfectly on my computers (database locally on SSD, album collection on network share with about 100k photos), so I can sync the whole database to a second computer and work on the same album collection in my local network. This is a really huge benefit and I love it.

Could you please have a look at the "Open With" menu option? For me it would be really nice if "open with" could be fixed to work with UNC-paths on Windows operating systems :) And I still belief it is the syntax with "//smb/path" instead of "\\smb\path" sent to the file handler in Windows. When I use the Windows-Run-Command with "\\smb\path" it will open correctly, when I use it with "//smb/path" I get the same error message as the menu-option "open with..." in digiKam.
Comment 3 Benny 2020-03-28 15:38:16 UTC
Created attachment 127063 [details]
Configuration - Collections on Network Shares
Comment 4 Maik Qualmann 2020-03-28 15:58:09 UTC
Git commit 165812233481f5698d4fb803a7ba4efe9a6191a9 by Maik Qualmann.
Committed on 28/03/2020 at 15:56.
Pushed by mqualmann into branch 'master'.

try to fix "Open With" under windows with network path

M  +1    -1    core/app/items/utils/contextmenuhelper.cpp

https://invent.kde.org/kde/digikam/commit/165812233481f5698d4fb803a7ba4efe9a6191a9
Comment 5 Maik Qualmann 2020-03-28 16:03:18 UTC
So far I have assumed that Exiv2 cannot use network paths if it works - ok. Gilles is currently unable to build new Windows bundles due to network bandwidth issues caused by COV-19. I'm going to build an up-to-date bundle that will take some time because my MXE needs to be rebuilt.

Maik
Comment 6 Maik Qualmann 2020-03-31 05:52:45 UTC
The "Open With" function now also works with network paths. I now close the bug.
You can currently download an updated version of Win64 from my GDrive. This version is exactly like the official test versions and virus free, because it is compiled and packaged under Linux.

https://drive.google.com/open?id=1zAWU_i9UdRKUD42_akz0b5ljL6tcEXtO

---------- Compute installer checksums for digiKam 7.0.0-beta3

File       : digiKam-7.0.0-beta3-20200331T065626-Win64.exe
Size       : 188M
MD5 sum    : d0407e53960f0809b9b7e17c02dc42b1
SHA1 sum   : 749e0e50257c452d54a48f24dfc99b3f4acd01ed
SHA256 sum : 5b9f8827558bab93e14607e0b4bfc8e081f306a80e01e234c7a9c4dc47c812e6

Maik
Comment 7 Benny 2020-03-31 22:02:04 UTC
Created attachment 127149 [details]
This file does not have an app associated with it for performing this action.

Dear Maik, thank you very much! It's working and I can choose a program to open my images with on my network share and I am very happy that you've fixed it that fast!

But every once in a while Windows displays an error message (I've attached the german version):
"This file does not have an app associated with it for performing this action. Please install an app or, if one is already installed, create an association in the Default Apps Settings page." 
If I try again the "Open With" option it's working as it should... This happens every 2 to 5 times.

I've tested this on two different Windows PCs, one with W10 1903 and one with W10 1909, checked with JPG, HEIC and MOV. Both running your beta3. And it seems to happen only with UNC-Paths, on a local collection it does not happen so far.

Should I open a new bug? Or maybe it's a Bug in Windows...
Comment 8 Maik Qualmann 2020-04-01 05:52:46 UTC
I cannot reproduce the problem quickly. Does it occur with a certain file type? If Windows actually does not know the file type, the question of searching in the App store comes up. I'm testing it more intensely tonight.

Maik
Comment 9 Benny 2020-04-01 05:56:58 UTC
No, it occurs with every file type I tested: JPG, HEIC and MOV so far. I just thought about that the problem may be caused by blanks in the path - but I don't know why it happens not every time using the "Open With" function.
Comment 10 Maik Qualmann 2020-04-02 05:59:44 UTC
I cannot reproduce the problem on 2 versions of Windows. A VM with Windows 10 and a real computer with Windows 7. Spaces in the network path have no influence.

Maik
Comment 11 Benny 2020-04-04 09:34:34 UTC
Created attachment 127260 [details]
Tested on a third device with clean install

Hi Maik, sorry for the delay. I tested the problem on a third Windows device (notebook with Win10 1909) with a clean install of digiKam 7.0.0-beta3 and the problem occurs.

I made a local share on D:\Temp, named it \\a507\Temp and added the collection to digiKam 7.0.0-beta3. Choosed "Open with" in the context menu, the first time worked, using the "Open with" function the second time on the same picture the error message appeared (please have a look at the screenshot).
Comment 12 Maik Qualmann 2020-04-04 16:09:10 UTC
Git commit 66f99e68426494b3a2d7c7dad98fe59b3bb8a13c by Maik Qualmann.
Committed on 04/04/2020 at 16:06.
Pushed by mqualmann into branch 'master'.

debug last error code from the Windows API

M  +1    -1    core/app/items/utils/contextmenuhelper.cpp

https://invent.kde.org/kde/digikam/commit/66f99e68426494b3a2d7c7dad98fe59b3bb8a13c
Comment 13 Maik Qualmann 2020-04-04 16:13:49 UTC
Your last example also works without problems here. The last error code is now output via debug. You have to install Microsoft DebugView to see the output. The Windows build is running, I publish the GDrive address here, please wait.

Maik
Comment 14 Maik Qualmann 2020-04-04 18:52:01 UTC
New Windows build with error code output:

https://drive.google.com/open?id=1klI1_RtIh793Mbt7oFui_tRJbD2cCQHc


---------- Compute installer checksums for digiKam 7.0.0-beta3

File       : digiKam-7.0.0-beta3-20200404T200159-Win64.exe
Size       : 188M
MD5 sum    : b9045284367e7f1b372800b283b718da
SHA1 sum   : a393f588359d0c0ff32845b6dccf53f38831e6e7
SHA256 sum : 6ce514439a3575aa9d5db6d8a1d5b9f673a5eced62dd3b58f14a9d481b423315

Maik
Comment 15 Benny 2020-04-04 19:14:49 UTC
This was kind of tricky, took a while to configure DebugView to capture it (had to enable "Capture Events"):

[4376] digikam.general: ShellExecuteEx::openas return code: 1223
[4376] digikam.general: ShellExecuteEx::openas return code: 0
[4376] digikam.general: ShellExecuteEx::openas return code: 0
[4376] digikam.general: ShellExecuteEx::openas return code: 0
[4376] digikam.general: ShellExecuteEx::openas return code: 0
[4376] digikam.general: ShellExecuteEx::openas return code: 0
[4376] digikam.general: ShellExecuteEx::openas return code: 0
[4376] digikam.general: ShellExecuteEx::openas return code: 1223

The first an the last failed with the known message.
Comment 16 Benny 2020-04-04 19:35:48 UTC
I hope it helps narrow down the issue :) And thank you for your time and support!

If I could assist you any further we could also do a teamviewer session, if you want to do any further debugging on this?
Comment 17 Maik Qualmann 2020-04-04 20:06:40 UTC
The error code 1223 means "ERROR_CANCELLED". This is probably due to the fact that the dialogue was canceled by the user.

If I try to open an unknown file type, I get a "modern" dialog with the suggestion to search the Windows App Store. Can you try to open an unknown file type, e.g. ORA, XCF or the like. What error message do you see?

Maik
Comment 18 Benny 2020-04-04 20:13:36 UTC
Created attachment 127278 [details]
Windows Dialog for Unknown Filetype

Hi Maik, this is what I get when I try to open a .123-file.
Comment 19 Benny 2020-04-04 20:26:12 UTC
Created attachment 127279 [details]
Recoreded with Problem Step Recorder

I've recorded the steps with the "Microsoft Problem Step Recorder" so you can see what I do :) RC 1223 only occured on the first an the last time. I think you need Internet Explorer to open the MHT file.
Comment 20 Benny 2020-04-04 20:38:39 UTC
Created attachment 127280 [details]
Recoreded with Problem Step Recorder (V2)

Another complete one...
Comment 21 Maik Qualmann 2020-04-04 21:42:50 UTC
New test version with "File:" URI in the path.

https://drive.google.com/open?id=1-ohkyvkD5zaHvCawHOOTBw0BCVoxvcyY

---------- Compute installer checksums for digiKam 7.0.0-beta3

File       : digiKam-7.0.0-beta3-20200404T224613-Win64.exe
Size       : 188M
MD5 sum    : 762840f347e057a8c5a2d021ff5894a6
SHA1 sum   : a2acabd17423815627e28dbec41eda650489ae37
SHA256 sum : bb5fbd5f21e22797dbd3fa23a614edd0fe0f5ed9738d3974affa3181ef74360e

Maik
Comment 22 Benny 2020-04-05 06:20:50 UTC
Created attachment 127287 [details]
Recoreded with Problem Step Recorder (V3)

Good morning Maik, thank you for the new version, but sadly it does not fix the issue. The message now shows File:\\smb\path in the title bar.
Benny
Comment 23 Benny 2020-04-05 08:05:56 UTC
Created attachment 127288 [details]
Screenshots from legacy windows versions

Hi Maik, i've done some testing on older Windows version (virtual machines):

Windows 7 does not like you're version with "File:", but even UNC is not working at all with the local test share - doesn't matter for me, because it's an old unsupported OS version :)
digiKam_win7_File-UNC.png
digiKam_win7_UNC.png

Windows 8 has the same issue with the open with dialog, sometimes it's working, sometimes not:
digikam_win8_openwith_keine-anwendung.png
digikam_win8_openwith_ok.png
Comment 24 Maik Qualmann 2020-04-05 09:36:19 UTC
I reopen the bug. I cannot reproduce the problem even on a 3rd Windows 10 computer. I don't know if it depends on the network. It is a simple Windows API call and we cannot do much more than pass the path. There is evidence on the web that Defender or an antivirus program is causing this error box. But why then only temporarily and the Defender is also active with me? We have to see if other users can reproduce. Maybe if he has a little time again, Gilles can try to reproduce it.

Maik
Comment 25 caulier.gilles 2020-04-05 15:37:16 UTC
Hi Maik,

Here at home, i just a Windows 10 VM without network share usable.

My second Windows 10 computer is a laptop for the office VPN works and i don't have the admin right.

I can try with the VM if i can reproduce this problem, but i'm not sure to be in the same configuration...

Gilles
Comment 26 Maik Qualmann 2020-04-05 15:54:45 UTC
Hi Gilles,

According to Benny, you can also create a share from local folder and add this share address as a network collection in digiKam. DigiKam shows the content of such a network collection without any problems.

Maik
Comment 27 Benny 2020-04-05 16:02:28 UTC
Hi Gilles, you don't need network access to test this issue. I've tested with a VM (in vmware Player), Virtual Machine Settings: Network Adapter: Not Connected.

Just make a local share (Windows Explorer > Go to e.g. C:\Temp, right click, Share... and a share "\\Your-PC-Name\Temp" is created).
Install DigiKam with default settings (C:\Users\Benny\Pictures).
Go to digiKam settings (Configure digiKam > Collections) and add the created share "\\Your-PC-Name\Temp" to "Collections on Network Shares".

If you cannot reproduce the isse, I could try to upload the VM (in German language).

Benny
Comment 28 Benny 2020-04-05 20:58:34 UTC
Hi Maik, Hi Gilles,

I give up. Sorry for wasting your time. I've tested for hours now and I can't find a root cause. Three physical Windows 10 systems reacting the same way, it doesn't matter if it is a local share or remote share. The error comes up every few times. The Windows 8 VM (from 2012, not updated at all) has the same behavior.

Now I've installed a clean Windows 10 1909 in vmware, created the local share and it's working! Updated to the latest Windows Defender updates and OS updates, connected to my network, and it keeps working. I am at my wit's end.

The physical Windows 10 system all have in common, that they've been upgraded over and over from previous Windows 10 versions... but else, on one Kaspersky security software is running, on the others Windows Defender. On two 1909 is running, on one 1903 with Windows Defender.

I checked about Windows Defender and Firewall (as you've mentioned Maik), disabled them. No changes. At the moment I believe it's a wired Windows bug. I can live with it, because everything else is running smoothly.

@Maik: Could you please remove the "File:" call again? It's running better without as far as I can see.

Thank you again for your fast support. And I love digiKam.
Benny
Comment 29 Maik Qualmann 2020-04-05 21:13:00 UTC
The path with "File:" URI was a local test version and was not committed to the git/master repository.

Maik
Comment 30 caulier.gilles 2020-04-06 09:06:11 UTC
Hi Benny and Maik,

I follow all step to try to reproduce the dysfunction using my Win10 fully updated with all last update (this take a while here as the network is overloaded by too much visio and VPN sessions), and finally after a long Microsoft reboot, i never reproduce the problem...

I used the last Windows installer 64 bits that i compiled yesterday evening and published on test download area...

https://files.kde.org/digikam/

Note for Maik : the gitlab bandwidth is back to the normal, after 3 weeks of degraded mode (30 Kbits/s instead 700 KBytes/s - yes note the bits versus bytes!). So i'm able to compile and upload all bundles every day now...

Gilles
Comment 31 Maik Qualmann 2020-04-06 15:48:57 UTC
Thanks Gilles for testing, I close the bug again for now.

Maik