Bug report #18337: Absolute paths stored in Qgis 3.0 project file for GDAL layers - QGIS Application - QGIS Issue Tracking

Bug report #18337

Absolute paths stored in Qgis 3.0 project file for GDAL layers

Added by Patrick Dunford over 6 years ago. Updated over 6 years ago.

Status:	Closed
Priority:	Normal
Assignee:	-
Category:	Project Loading/Saving
Affected QGIS version:	3.0.0	Regression?:	No
Operating System:	Debian 9.3	Easy fix?:	No
Pull Request or Patch supplied:	Yes	Resolution:	fixed/implemented
Crashes QGIS or corrupts data:	No	Copied to github as #:	26227

Description

When raster layers are added to a project, the layers are stored in the project file with absolute paths, even though the project properties are set to relative paths.

Typical entries in project file:

&lt;customproperties/&gt;
        &lt;layer-tree-layer id="94CLL_92XFS20180306004423050794933680" name="94CLL-92XFS" source="/home/patrick/Maps/Qgis/Bugs/18322/C1/94CLL-92XFS.jpg" providerKey="gdal" checked="Qt::Checked" expanded="1"&gt;
          &lt;customproperties/&gt;

<datasource>/home/patrick/Maps/Qgis/Bugs/18322/C1/94CLL-92XFS.jpg</datasource>

When the project file is saved after adding the layers, it contains the absolute paths.

The project file path is /mnt/share/serverpc/sources/Root/Google Drive/NZ Rail Maps/Projects/CanterburyWestlandNelsonMarlborough/300btestb.qgs
Therefore one would have expected a relative path: ../../../../../../../../home/patrick/Maps/Qgis/Bugs/18322/C1/94CLL-92XFS.jpg approximately
Even although in this case the path refers to a network share hosted on another computer, it is mounted to a local path in the same computer.

I have seen relative paths used in a similar project file, where the raster layers and the project file were in different subdirectories off /mnt/share/serverpc/Sources

300btest.7z (69.2 KB) Patrick Dunford, 2018-03-05 12:49 PM

History

#1 Updated by Giovanni Manghi over 6 years ago

Category changed from Unknown to Project Loading/Saving
Status changed from Open to Feedback

I just tested on Windows (can't test on Linux right now) and can't confirm.

#2 Updated by Luigi Pirelli over 6 years ago

seems still open as reported also for 2.18

see #17824

#3 Updated by Luigi Pirelli over 6 years ago

also when set correct relative path in "handle bad layer", the project save always the <datasource> tag in absolute!

#4 Updated by Luigi Pirelli over 6 years ago

<editform> tag is also set as the project absolute path

#5 Updated by Luigi Pirelli over 6 years ago

in my case the error is not by the code but for my use of linked path

the construction of relative path is done here:
https://github.com/qgis/QGIS/blob/master/src/core/qgspathresolver.cpp#L199

but my project path is absolute without resolving the linked path, whilst the datasource have the linked path resolved probably here:
https://github.com/qgis/QGIS/blob/master/src/core/qgspathresolver.cpp#L158

so, we have this problems because the linked path is not completly expanded/resolved for the prohject path

Patrick can you check if you have the project and data in a linked path and test what happend if putting it in a clean path?

#6 Updated by Patrick Dunford over 6 years ago

It appears to me the relative function in Qgis 3 and 2.18 only works for relativity within the same root folder e.g. it will relative for everything being off the /mnt directory. When I use VMs accessing stuff over a network share, all the shares are mounted off /mnt so it seems to be able to produce relative paths for everything. The specific issues shown for this bug are coming from a physical PC where the resources are in different paths (e.g. some of the resources are off /mnt and some are off /home)

As such, while the question raised is a valid one, I don't think any software would be expected to be able to produce a truly portable file-path situation over the particular scenario I have used here so I am going to have to use symlinks to link the home directory path on my home computer into the mnt path so that the files all resolve into the same root folder regardless of network or local file access.