Can’t you copy over the old db to the new paths? The app should be able to access the old “harbour-foobar” directories when using the new sandbox profile.
I guess this matches up with the Firejail man page for a whitelist entry:
Now if you consider using a whitelist in your application profile, be aware that:
Indeed, it has been designed for migration and it helps to copy data from the old directory to the new location. My remark was more about ‘was it possible, by not giving an organisation name, to get the old behaviour ?’ The answer is yes, but only for existing installations, which means ‘no’ in general for this specific question.
I was implementing migration of the storage folders of Whisperfish (Rust application), when I noticed that I could not simply move (i.e. std::fs::rename) the folders from the old to the new location if started with Sailjail (i.e. normally from the launcher icon). I had to copy-and-delete the files in them recursively instead. Luckily there’s a crate that provides fs_extra::dir::move_dir which does exactly that!
I believe this is because Sailjail mounts the old storage folders separately from the new ones, and as such they appear to be in different filesystems (mount points).
Hopefully this piece of information helps with others struggling with failing moves - although it looks like QDir::rename tries to move, and falls back to copy-and-remove automatically.
2 Likes
Can we have the information gathered in this thread put into the documentation/wiki?
At least I can’t find it there.
1 Like
It definitely should be there. The only reason it isn’t is that no one has added it there. I think this would be a perfect place: Application Permissions | Sailfish OS Documentation PRs are welcome 
1 Like
Is there now another recommended way for dealing with this in pure QML apps (like podqast) without disabling sandboxing alltogether?
Unfortunately, no 
Nemo.FileManager is not allowed in harbour, but its FileEngine provides methods to rename files, which should work to do similar things as the above methods do. Particularly:
Method {
name: "mkdir"
type: "bool"
Parameter { name: "path"; type: "string" }
Parameter { name: "name"; type: "string" }
Parameter { name: "nonprivileged"; type: "bool" }
}
Method {
name: "rename"
type: "bool"
Parameter { name: "fullOldFileName"; type: "string" }
Parameter { name: "newName"; type: "string" }
}
To be harbour-compatible, I guess the only way is XMLHttpRequest, one with ‘GET’ to load a file to memory, and one with ‘PUT’ to save it to a new location.
Please be aware that the values of StandardPaths vary depending on when they are set, and LocalStorage location is not covered by them:
1 Like
Hey, this thread is a bit long so I skimmed over parts, if I understand it correctly I will need to release an “in-between” version that migrates the settings etc. before I can activate sailjail on gPodder since there is no “clean” solution for pure QML apps? (in my quick tests I had access to either/or but not both locations)
And anyone who happens to skip the in-between version will have a crap experience while even now people also have a broken experience due to the default profiles… 
I have had my sailphoto app removed from the store because of this broken experience. Tried to get it working again, without migrating the db, but now I read “Please be aware that the values of StandardPaths vary depending on when they are set, and LocalStorage location is not covered by them” so no success, sadly …
All you need is to copy data from the old location to the new location. As I remember an app with small Sailjail rights can read the old settings. For my apps I use a little c++ code but you can do this alsoer in pure QML. When your app starts just read the old settings and store them to the new location. Set a bit in the old settings to document the transfer to avoid further transfers. Later you can delete the old settings, maybe 3 month later or so. And in a later release of your app you can remove this setting copy code. Of course you must hardcode the path to the old settings. Standardpaths only provide the new settings.
But if you read or write data elsewhere in the filesystem, not only in the old or new Standardpaths, you need the Sailjail right to read there. Add the right in your desktop file for this release.
Good luck.
Have you some details of the described problem?
The values of StandardPaths can change with system changes. Thats the reason for this functions.
From what I saw - the moment I setup a proper sailjail profile with the names as they “should” be I lost access to the old folders, from skimming through this topic this seems to be an issue with pure QML apps, I need to double check my observation though.
Please test if this is right or wrong for the “old” setting directories. I assume you has save your old settings at the location provided by the old “StandardPaths”…
Hey, sorry for the delay.
From some more testing it seems that the issue was not with the sandbox but when I tried to set gPodder progname (variable internal to gpodder-core) to match the sandbox name it also impacts where it looks for files so I will be writing migration functions soon 
2 Likes