Session file with external file reference can't resolve linux path

[anonymous]

What steps will reproduce the problem?

1. Opening a previously saved session file, containing a layer connected to a local opendata file.

What is the expected result?

Earlier, JOSM warned a layer file could not be found, and offered to remove the layer before opening the session, which worked, and the file could just be added again. (Of course best option is the session file saves a correct path, but I can't remember this to ever have worked...)

What happens instead?

Now, JOSM just throws an exception, opens the bug reporter, and don't seem to be able to open the saved session at all... :(

Please provide any additional information below. Attach a screenshot if possible.

I'm on Linux, which probably is important since it seems like the saved path is the problem. The stack trace shows a full filepath prefixed with a variable for $HOME which resolves to a path that doesn't exist. If a correct file path can't be saved, I would at least have the previous behaviour of a soft error with the option to remove the supposed faulty layer.

Last errors/warnings:

• 00600.165 E: Handled by bug report queue: java.lang.RuntimeException: Unable to obtain connection: path to 'home/<user.name>/gis/gävle/baskarta-adresser.gpkg': '${HOME}/home' does not exist. Anledning: java.sql.SQLException: path to 'home/<user.name>/gis/gävle/baskarta-adresser.gpkg': '${HOME}/home' does not exist

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2024-08-28 22:00:04 +0200 (Wed, 28 Aug 2024)
Revision:19207
Build-Date:2024-08-29 01:30:31
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (19207 sv) Linux Fedora Linux 41 (KDE Plasma Prerelease)
Java version: 22.0.2+9, Red Hat, Inc., OpenJDK 64-Bit Server VM
Desktop environment: KDE

Plugins:
+ DirectDownload (36298)
+ PolygonCutOut (v0.7.3)
+ apache-commons (36282)
+ ejml (36176)
+ geotools (36273)
+ jackson (36273)
+ jaxb (36118)
+ jts (36004)
+ notesolver (0.5.0)
+ opendata (36327)
+ tageditor (36298)
+ utilsplugin2 (36298)


=== REPORTED CRASH DATA ===
BugReportExceptionHandler#handleException:
No data collected.

Warning issued by: BugReportExceptionHandler#handleException

=== STACK TRACE ===
Thread: AWT-EventQueue-0 (36) of main
java.lang.RuntimeException: Unable to obtain connection: path to 'home/<user>/gis/gävle/baskarta-adresser.gpkg': '/home/<user>/home' does not exist
	at org.geotools.jdbc.JDBCDataStore.createConnection(JDBCDataStore.java:2293)
	at org.geotools.jdbc.JDBCDataStore.createTypeNames(JDBCDataStore.java:945)
	at org.geotools.data.store.ContentDataStore.getTypeNames(ContentDataStore.java:261)
	at org.openstreetmap.josm.plugins.opendata.core.io.geographic.GeotoolsConverter.convert(GeotoolsConverter.java:77)
	at org.openstreetmap.josm.plugins.opendata.core.io.geographic.geopackage.GeoPackageReader.parse(GeoPackageReader.java:59)
	at org.openstreetmap.josm.plugins.opendata.core.io.geographic.geopackage.GeoPackageReader.parseDataSet(GeoPackageReader.java:44)
	at org.openstreetmap.josm.plugins.opendata.core.io.geographic.geopackage.GeoPackageImporter.parseDataSet(GeoPackageImporter.java:26)
	at org.openstreetmap.josm.gui.io.importexport.OsmImporter.loadLayer(OsmImporter.java:121)
	at org.openstreetmap.josm.io.session.OsmDataSessionImporter.importData(OsmDataSessionImporter.java:106)
	at org.openstreetmap.josm.plugins.opendata.core.io.session.OpenDataSessionImporter.load(OpenDataSessionImporter.java:27)
	at org.openstreetmap.josm.io.session.SessionReader.parseJos(SessionReader.java:609)
	at org.openstreetmap.josm.io.session.SessionReader.loadSession(SessionReader.java:834)
	at org.openstreetmap.josm.io.session.SessionReader.loadSession(SessionReader.java:783)
	at org.openstreetmap.josm.actions.SessionLoadAction$Loader.realRun(SessionLoadAction.java:204)
	at org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.java:94)
	at org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.java:142)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1570)
Caused by: java.sql.SQLException: path to 'home/<user>/gis/gävle/baskarta-adresser.gpkg': '/home/<user>/home' does not exist
	at org.sqlite.SQLiteConnection.open(SQLiteConnection.java:261)
	at org.sqlite.SQLiteConnection.<init>(SQLiteConnection.java:67)
	at org.sqlite.jdbc3.JDBC3Connection.<init>(JDBC3Connection.java:28)
	at org.sqlite.jdbc4.JDBC4Connection.<init>(JDBC4Connection.java:19)
	at org.sqlite.JDBC.createConnection(JDBC.java:104)
	at org.sqlite.SQLiteDataSource.getConnection(SQLiteDataSource.java:464)
	at org.sqlite.SQLiteDataSource.getConnection(SQLiteDataSource.java:456)
	at org.geotools.jdbc.JDBCDataStore.createConnection(JDBCDataStore.java:2277)
	... 20 more

[stoecker]

Is the path correct when starting with /home instead of only home?

Seems the wrong path issue is the stripped /.

Beside this the bug dialog instead of asking is clearly a second bug.

[anonymous]

Yes, the correct path is '/home/<user>/gis/...' including the single preceding slash.

Going by these two rows it seems there is a variable for $home that includes '/home/<user>/' with a trailing slash, so the saved path probably shouldn't have the slash. But it includes home/user as well, so that part seems doubled in the resolved path.

path to 'home/<user.name>/gis/gävle/baskarta-adresser.gpkg': '${HOME}/home' 
path to 'home/<user.name>/gis/gävle/baskarta-adresser.gpkg': '/home/<user>/home' does not exist

[anonymous]

I have now extracted my .jos file and it seems the layer file path saved is the correct full path with preceding slash:

        <layer index="1" name="baskarta-adresser.gpkg" type="open-data" version="0.1" visible="true">
            <file>file:/home/<user.name.redacted>/gis/gävle/baskarta-adresser.gpkg</file>
        </layer>

What exactly is stored in ${home}, and how/why the file path tries to resolve with it, i do not know.

As mentioned, the path resolving has never worked for me. The supposed regression now is the hard exception that doesn't even allow for removing the layer so the session can be opened. let me know if there should be a second bug report.

[stoecker]

Replying to anonym:

What exactly is stored in ${home}, and how/why the file path tries to resolve with it, i do not know.

Seems somewhere in processing the "/" gets lost making it a relative path and that's where $HOME comes in. Fix is to find the place where the "/" gets lost ;-)

[skyper]

Replying to stoecker:

Replying to anonym:

What exactly is stored in ${home}, and how/why the file path tries to resolve with it, i do not know.

Seems somewhere in processing the "/" gets lost making it a relative path and that's where $HOME comes in. Fix is to find the place where the "/" gets lost ;-)

So, this would fix the current bug that the correct path is somehow passed improperly.

Replying to anonymous:

As mentioned, the path resolving has never worked for me. The supposed regression now is the hard exception that doesn't even allow for removing the layer so the session can be opened. let me know if there should be a second bug report.

I guess a new ticket would be useful as there are many possibilities for a layer to be unavailable like renaming/moving a file or an external device not being mounted (at all or to a different mount point). It should still be possible to open the session without this layer. The exception should be caught and a message should be presented.

[stoecker]

Replying to skyper:

I guess a new ticket would be useful

I don't think a new ticket is necessary in this case.

[stoecker]

I can't reproduce the bug with OSM and GPX files. For me file names in the session file are correct and also correctly opened. When the file name is wrong I get a dialog to skip the layer and loading continues.

I could reproduce with a .gpkg file, so it's a plugin issue.

[stoecker]

In 36337/osm:

fix #23928 - correctly handle saved file path

[stoecker]

In 36338/osm:

see #23928 - correctly handle saved file path (release)

[stoecker]

For me fixing the base issue also fixed the loading in case of missing files. I didn't investigate further.

[anonymous]

Replying to stoecker:

For me fixing the base issue also fixed the loading in case of missing files. I didn't investigate further.

I updated opendata plugin with your fix and my session file opened perfectly, loading all the .gpkg objects! =D I also tested with a missing file and the skip layer dialog showed as expected

Thank you so much, @stoecker ! I'm very happy =D