Yes, but this solution sounds more like for users installing from chum/openrepos.
Whereas those from Harbour ‘should’ not’ be bothered with such activity. Quite counterproductive, or?
Telling peeps to counterfeit the security mechanism to be safe
The migration will work as is, just kills peoples storage devices, I put 30G of extra writes on my phone before I understood what was happening….
Another trial&error idea (without any knowledge 
): did you whitelist the new (default sailjail folders( explicitly? Maybe there is a difference?
Forget this, as of writing I cleared up my foggy mind. The original folder is still located outside of the jail and I am pretty sure sailjail does not allow moving of folders “outside” of the sandbox.
Both folders are in the Jail, that part was handled nicely by Jolla, the problem is they are not part of the same filesystem as far as programs inside the jail can tell.
Hmm, I did not even bother to take over the old configuration of Defender (two few bytes files), so I really did not look into this. And cannot be helpful.
For these kind of problems I would like to know which part at @Jolla was responsible for exactly this area (here:sailjail) to address a question directly.
I’m not very good today in understanding the issue here. When SailJail come about us I added a C++ function to my apps. This function will call by start and looks if the config data in the new SailJail folder. If not, the files from the old folders (via hardcoded path) will be copied in the new folder (via StandardPath). Maybe the app must be restart. But that’s all. Such a method is also descriped in Viges blog mentioned above.
Is there something more or others behind the topic here? When yes, please excuse me.
@hanswf I also have working migration logic, the problem is that many of my users have many GB worth of data and while a mv/os.rename is instantaneous and “costs” nothing at the OS level when it is to 2 paths on the same filesystem the sandbox causes the paths to be seen as different paths which in turn triggers a process that can be many minutes long depending on the size of the dataset and also causes needless wear&tear on the users’ phone.
Thanks for explaining. This is indeed a special case. My first & frivolous idea here: If you show a message like “one time data migration is needed and the process will eat some minutes, please wait” our users have enough experience to accept this.
I will follow this thread to learn what will be your solution. Thanks.
I know it’s not the perfect solution, but you could ask users to do it themselves, in the CLI, so no cross-mount moving is necessary.
You can help cli-inexperienced users by providing a shell script which does the right thing in e.g. /usr/share/harbour-gpodder/lib/migration.sh, and I’m sure it’s possible to do it through some (unjailed) file manager as well.
1 Like
I didn’t read everything here, but did you OP know that sailjail is just a thin wrapper around firejail, which has ample documentation?