Home / GitHub Page

Android 10/Q and Syncthing Future

This is a heads up for those who use Syncthing on Android about future problems that may be coming your way.

I use the Syncthing-fork app and noticed in the most recent release notes a warning that Google’s use of scoped storage and kernel restrictions may lead to Syncthing breaking completely and with no way to fix it. The current sentiment seems to be that this could completely end Syncthing on Android.

Most of this is over my head, but More from the Syncthing-fork developer here: https://github.com/Catfriend1/syncthing-android/issues/457.

For me this world mean having to completely change my current sync approach for Joplin and several other things as well.

I’ve moved the topic to #lounge, because the #apps category is for scripts and apps that make use of Joplin. IMO Syncthing does not fit the profile.

Good call. Wondered about that, but description for apps said third party, but now realizing that’s third party Joplin apps. :+1:

It’s a trend I really dislike about Android. They are taking away more and more user-friendly features and locking down devices in the name of “security”. Security all relative since of course Google apps have full access to everything.

For now, I guess we can only expect things to go that way, and it will more and more difficult to use Joplin filesystem sync in Android.

While I certainly hate how they mess with the filesystem access every few years (WHY? even going back 20 years Linux probably had enough access control features even for decent servers, never mind for small mobile devices that are in most practical implementations single user - I mean end-user as the apps run under different UIDs) I also don’t fell comfortable to sync a sqlite db at filesystem level. Maybe it’s much better after all to just use Joplin’s fancy sync mechanism.

Maybe I have misunderstood the setup, but with Syncthing, I believe the assets (.md files and attachments) are what are synced. Joplin still does it’s own sync and get’s the DB up to date, separate from the Syncthing file movement stuff

Regardless, if Syncthing will soon cease to be a functional item for Android, I will have to move to a different sync system for my various files - Joplin stuff included. Looking more and more like I will move towards Nextcloud. I have an older desktop that I’m toying with converting to a FreeNas box at home, and putting a Nextcloud instance on that. Just not sure I want to put the time into learning what all I’d need for that.

Nextcloud is a cloud, not a sync tool. You can upload/download on demand, but no sync.

I’m (wildly) guessing here too as I’m not using Syncthing but I’m not even sure that’s possible - to separately sync the db with Joplin’s sync and the files by themselves. And also not sure why that would be desired as you need to configure two things while Joplin can do everything by itself.

“cloud” doesn’t mean a thing. In Joplin’s context Nextcloud refers only to sync - it’s configured under Synchronisation “chapter” specifically as “Syncronisation target”, the button to do it is called “Syncronise” and it does what you would expect when using multiple devices.

Yes, we have a mixup of terms here.

Joplin: Local Joplin data is synched with a cloud server, and vice versa. All Joplin clients that synch with that server will show the same notes, resources, etc…

SyncThing: Local folders are synched (usually two-way) with other peers. In the case of two-way synch, all peers have the same file data.

Nextcloud: All clients have access to the collection of files on the server. Up/Download on demand of cloud files and local files.

So the three forms are fundamentally different, but can be perceived to lead to the same results: identical data on all clients.

EDIT: On Linux, the Nextcloud client performs a two-way folder sync.

Yes, on Windows and MacOS as well. It would on mobiles too probably if we didn’t have this “war on filesystem access”.

Because this is totally over my head I ask whether using Joplin on “degoogled” mobile OSs like /e/ would insulate the user from the problems mentioned above?

As far as I understand Joplin’s own sync will have no trouble writing the data where it needs to, it’s the filesystem sync programs (like syncthing) that would have a problem. I can’t comment why one would use that instead of the native sync, probably because they have it already setup and it works well or because they don’t have and don’t want a "server"and Syncthing works without one, I don’t know. Maybe somebody using such a setup can tell us.

On the other hand virtually all “alternative ROMs” de-Googled or not allow root access and/or have much more flexibility in giving more permissions to applications, changing rights in the filesystem, mounting partitions with different options, etc. It would be very easy to work around such limitations there and have syncthing and similar work without trouble.

1 Like

If I understand the signs correctly, the Linux (Mac, Windows) clients will also switch to a ‘virtual drive’ approach… You see the files but they are not physically resident on the client until you need them.

It has certain advantages, i.e. you don’t need the full disk space.

Joplin shows notes that are contained in a private area and synchs its data with a cloud server. No filesystem access problems involved.

Some users seem (for ununderstandable reasons) to want to synch the Joplin data area using file system sync tools (FolderSync, SyncThing). Lots of filesystem access problems involved. Plus risks of data loss due to database curruptions.

Well, for Android 10 we’ve settled it with an exception I’ve applied for. Google may withdraw it anytime by changing gplay policies. The next problem will be android 11 where they won’t allow the exception from the hated scoped storage feature anymore.

Discussion is taking place here - ideas are welcome if anyone knows how to get the SyncthingNative access to the whole internal and extsdcard storage readwrite like we used to.

Maybe Google should answer how they expect such an app to work.

I’m sure they did this on purpose to promote their cloud solution. The permission/security excuse only works so far, especially when Google gives apps like Uber unprecedented privileges.