Unable to open a project in Windows via drag&drop, when the project is stored in a GPKG file on a mapped drive or a drive that is not C:

[cxcandid]

What is the bug or the crash?

We cannot open a QGIS project in Windows via drag&drop, when the project is stored in a GPKG file on a mapped drive. QGIS complains that the URI is invalid. Everything works fine if we open the project via QGIS Browser, or move the GPKG file to a local drive. "Open From... > Geopackage" works as well. There is even no error when we open a project from a GPKG file stored in SharePoint using WebDAV.

Steps to reproduce the issue

Store a QGIS project inside a GPKG file and put that file on a mapped drive (i.e. X:).
Then try to open the project via file drag&drop.

Versions

QGIS 3.22.3 Windows

Supported QGIS version

• I'm running a supported QGIS version according to the roadmap.

New profile

• I tried with a new QGIS profile

Additional context

No response

[jfmoyen]

Similar issue using a physical drive on the same computer (D:).
3.22.3-Białowieża
Révision 1628765
Windows 10

[gioman]

Similar issue using a physical drive on the same computer (D:).
3.22.3-Białowieża
Révision 1628765
Windows 10

@jfmoyen can't confirm this, just tested on Win10 and 3.22.3

[jfmoyen]

Interesting, so there would be something wrong with my file. Let me investigate, I'll come back to you. I wonder if it may be related to the OP's issue.

[jfmoyen]

GEO001M_exp.zip

This, for instance, does open happily if I drag it from C:\users\me\documents but not from D:\GISData\France\BRGM\France_1_000000

No, the D-path does not contain any space or weird characters, and it is not specially long, either.

This is the actual error I get:

Please let me know if there is something else you'd like me to try.

[gioman]

This is the actual error I get:

@jfmoyen yes, I was too quick before, D&D from d: drive and the selecting the project saved in the GPKG will result in that error.

[cxcandid]

I can confirm that it only works from C: drive.

[cxcandid]

Is there anything we can do to get this issue solved? ... sponsoring? 🤔🙄😊

[nicogodet]

@cxcandid Sponsoring could be a solution indeed

[cxcandid]

In QGIS 3.30.3 (Windows) D&D works from D: drive as well, but not from USB and not from any mapped network drive.
If I open a network directory via UNC path in Windows Explorer, D&D works pretty well.

[cxcandid]

In QGIS 3.36.0 project opening from GPKG via drag&drop doesn't work from D: drive anymore 🙁. C: drive is ok and UNC path is supported.

[agiudiceandrea]

Hi @elpaso, I've seen that you previously fixed with PR #33265 the logic for handling the project in a GeoPackage file. Anyway it seems it is still not working on Windows when the GeoPackage file is in a drive different from the C: drive (actually QGIS install drive letter) and such GeoPackage file is dropped onto the QGIS main window.

I've tracked down the issue to the point that in such case (e.g. a gpkg file file_name.gpkg in D:\) QgsGeoPackageProjectStorage::readProject is called with uri = geopackage://D:/file_name.gpkg?projectName=project_name (see the double slash).
Then, in QgsGeoPackageProjectStorage::decodeUri, the uri string doesn't match with the QRegularExpression (^[A-Za-z]:), so it is checked the existence (QFile::exists) of url.path() (where url = QUrl::fromEncoded( uri.toUtf8() ) = QUrl('geopackage://d/file_name.gpkg?projectName=project_name') ) which in this case is /file_name.gpkg (see the missing drive letter) and thus QFile searches the file in C: (actually in the QGIS install drive letter) and it doesn't find it.

On the contrary, when such GeoPackage file is opened via Project->Open From->GeoPackage, then QgsGeoPackageProjectStorage::readProject is called with uri = geopackage:D:/file_name.gpkg?projectName=project_name (see the missing double slash), so it is checked the existence (QFile::exists) of url.path() (where url = QUrl::fromEncoded( uri.toUtf8() ) = QUrl('geopackage:D:/file_name.gpkg?projectName=project_name') ) which in this case is D:/file_name.gpkg (see the presence of the drive letter) and it correctly finds it.

Maybe you know a simple way to fix it.