search

eclipse-archived / smarthome

Eclipse SmartHome™ project
https://www.eclipse.org/smarthome/
Eclipse Public License 2.0
863 stars 782 forks source link

StorageService can fail if the userdata path is not absolute #5540

Open Simiil opened 6 years ago

Simiil commented 6 years ago

During execution the jsonstorage service encounters the following error:

07:57:09.230 ERROR o.e.s.s.j.internal.JsonStorage[:275] - Error writing JsonDB to userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json. Cause userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json (No such file or directory).
07:57:09.230 ERROR o.e.s.s.j.internal.JsonStorage[:275] - Error writing JsonDB to userdata/jsondb/backup/1525672629230--org.eclipse.smarthome.core.thing.Thing.json. Cause userdata/jsondb/backup/1525672629230--org.eclipse.smarthome.core.thing.Thing.json (No such file or directory).
07:57:09.244 ERROR o.e.s.s.j.internal.JsonStorage[:275] - Error writing JsonDB to userdata/jsondb/org.eclipse.smarthome.core.thing.link.ItemChannelLink.json. Cause userdata/jsondb/org.eclipse.smarthome.core.thing.link.ItemChannelLink.json (No such file or directory).
07:57:09.244 ERROR o.e.s.s.j.internal.JsonStorage[:275] - Error writing JsonDB to userdata/jsondb/backup/1525672629244--org.eclipse.smarthome.core.thing.link.ItemChannelLink.json. Cause userdata/jsondb/backup/1525672629244--org.eclipse.smarthome.core.thing.link.ItemChannelLink.json (No such file or directory).

The files do exists and are at the correct location. After some debugging it seems that this occurs only after calling some native driver code (which is unfortunately proprietary code). calling exists() on the dataFile of the jsonstorage returns false. calling dataFile.getAbsoluteFile().exists() returns true. I found that a simple fix is initializing the jsonstorage with the absolute file.

specifying an absolute path for the userdata in the system properties works as

The system smarthome runs on is Linux on an openjdk 8 VM

sjsf commented 6 years ago

Sounds like the mentioned "proprietary native code" changes the current directory - but that's just a guess, obviously... We could try making JsonStorageService robust against that, but I cannot tell what else will break instead. Clearly, changing the current directory of the java process isn't exactly polite and generally can lead to pretty unexpected consequences. I'd primarily consider this a flaw in the above mentioned native code.

maggu2810 commented 6 years ago

If the CWD is changed, there could be problems all the time if a directory is accessed relative on any point later in time.

This could perhaps solved for ESH related stuff if ESH provides a "resolvePath" method. The implementation could the absolute paths for userdata, ... (all the config constants methods) on the beginning (service activation time). The method could e.g. consume two arguments, one enum that defines the "parent" (e.g. USERDATA, ...) and a path relative to that parent.

But if e.g. the system property for userdata has been changed on runtime, this would be broken again (but perhaps we could state that this is not supported at all).

I don't know if we need this as changing the CWD could break all non-ESH code, too (but at least we as "ESH" are safe then).

davidgraeff commented 6 years ago

I'm doing checks in my contributed code for relative/absolute paths as well. Most of the time by wrapping the Configs.userDataDirectory() (please insert the correct call here) with Paths.get(...).toAbsolutePath(). ESH predates Java 1.8. Maybe it helps to add a method now that returns a Path (resolved to an absolute path) directly and adapt the codebase?