Sorry that I’m rehashing this, I just finally made build of gPodder with SailJail that I intended to publish to a limited group first but I was having some issues (which I still need to check more), from basic observations (that I still need to recheck) it seems that after the first run the app no longer has access to the old paths even if migration was deferred by the user, is this correct?
2 Likes
Within SailJail, you have access to /home/defaultuser/.local/share/OrganizationName/ApplicationName/
My gpodder folder is /home/defaultuser/.local/share/harbour-org.gpodder.sailfish/
This has not the same structure, so no, the files are not accessible within SailJail.
Use Qt::StandardPaths or the QML + JS StandardPaths object to retrieve the correct path.
I think using SailJail correctly is worth it. I’d rather manually migrate my files, than set permissions to access my old files.
Maybe a first launch popup with migration instructions is a good solution?
1 Like
There is something about how SailJail allows access to the old paths at the very least the first time it is changed, I’m trying to understand that part of the process and if I can somehow “extend” this access while the user is deferring migration.
I don’t think access to old stuff expires. Some things are read-only, but that’s it.
I’m still trying to debug this, but anecdotally this does not seem to be the case, I moved all folders back to their original paths and started gPodder through the menu (which is inside of a SailJail) and it did not detect any of the unmigrated folders.
If OTOH I start it with sailfish-qml which bypasses SailJail it will detect the folders and migrate them.
Hmm based on more debugging it seems that the issue is not access but rather the order in which folders are created making gPodder think there might be a data collision (my assumption was that until I create those folders they would not exist but it seems they exist just by opening gPodder).
If said folders were never actually designated/well-formed for per-app data, but just annexed - then you are SOL of course.
What ones are you talking about?
But it it worked once, chances are it is you copying that is off. I just installed an older version of my app to get the old directories and contents back. I don’t believe i ever lost access to the old data for external reasons - if i was Jolla, that logic is a bug-farm i would not wish to own.
Presumably you have seen this thread?
you could give it the media permission, then it can access Pictures, Videos and Music paths.
Well, it does allow access to old folders, BUT it has no way to know what the old folders were.
So makes the assumption that the old name was appname (as in harbour-foo, not as in ApplicationName).
So if an non jail configured app is launched by SailJail, OrgName and AppName are set to harbor-foo (actually the executable/binary name).
So the local dir is ~/.local/share/harbour-foo/harbour-foo.
Now, in a pre-Sailjail world, apps would often store their stuff in So the local dir in ~/.local/share/harbour-foo/something.ini.
These two paths (actually just one path) are whitelisted and read-only, allowing for migration.
If you now configure harbour-foo for SailJail, and give it OrgName “the.foo.org”, and AppName “MyFoo”, the new whitelisted dirs become ~/.local/share/the.foo.org/MyFoo,
with become ~/.local/share/the.foo.org/ being read-only.
I think ~/.local/share/harbour-foo is still accessible read-only if the binary is still named harbour-foo but I’m not sure.
If the binary name changed, SailJail has no chance of determining the old path.
Anyway, launching
sailjail -D -p desktopname /usr/bin/app
Should give some indication of what is whitelisted.
Oh, and a caveat: LocalStorage location is NOT managed by sailjail, or rather Qt uses its own separate path by default which is not SailJail compliant.
Same goes for QSettings which by default uses .../organizationName/applicationName.ini which also fails under SailJail (to write, it does work for reading if the ini exists).
My suspicion based on what I saw on Friday is that when the application is started through the SDK it is started basically the same way as when you start it with sailfish-qml appname which in turn means it is running without SailJail and also allows the application to “manage” its own files.
When on the other hand the application is started via the menu it gets encapsulated by SailJail and here is what tripped me up -
SailJail pre-creates .local/share/OrgName/AppName .cache/OrgName/AppName and .config/OrgName/AppName
So when I tested with the SDK it just migrated everything fine and nobody was any the wiser, but when I created an RPM and tested on my phone the migration logic which checks for the existence of the new folders as a sign of a previously botched migration and backs off was triggered.
I’m going to change that logic to be ‘check that the target folders are empty’ instead of ‘check the exist’ and I’ll report back.
Here’s another curveball that I am less than thrilled about which I suspect is related to SailJail -
When trying to rename the files it returns Invalid cross-device link:
On my phone I am not using an external SD card or tricks like symlinks etc. is there any way to allow normal moves even inside the SailJail? os.rename (ie. simple mv) is orders of magnitude less “expensive” than shutil.move under these constraints both in time (on my phone full migration takes many minutes whereas a mv is instantaneous) and in completely unneeded writes causing extra wear to the phone memory.
What exactly are you trying to move?
The gpodder folders -
.local/share/harbour-org.gpodder.sailfish → .local/share/org.gpodder/gpodder_sailfish
.config/harbour-org.gpodder.sailfish →.config/org.gpodder/gpodder_sailfish
.cache/harbour-org.gpodder.sailfish →.cache/org.gpodder/gpodder_sailfish
I’d guess that at least the first ones there are mounted read-only… but that’s indeed just a guess.
Are you trying to “move” a folder from outside of sailjail into the jail?
Without being heard at court and without attorney? Probably even without a verdict? 
I am afraid that is against any ….
I am not sure but maybe whitelist the original one as well?
Or let the spec (pre) handle that for you? Only negative aspect is this is not possible for harbour 
The original is also whitelisted, the issue is probably that the folders are mounted into the sandbox individually which makes them “cross fs boundaries” even though they are on the same filesystem.
What do you mean? Also this is in OpenRepos and Harbour.
Harbour will not allow a pre scriptlet where you could easily move those folders with a simple ‘mv’ after check of existence of destination.
For chum and openrepos this would be the simple solution.
Yeah, right now my suggestion (though in my mind also terrible) is that people start gpodder directly from the CLI which bypasses the sandbox for the migration as I really don’t want to be responsible for unneeded wear on the flash memory.