Changes not detected by android when synchronizing

[deb75]

Hello,

I use orgzly with a local repository /storage/emulated/0/org

This repository is synchronized with distant ones using syncthing. On android, this app is able to watch directories and detect any file changes.

However, I noticed that when I modify an existing org file with orgzly, syncthing does not detect it. If I modify the same file with a simple android text editor, syncthing detects it right away.

I am not sure of myself, I just wonder what is happening, why orgzly modifications are not detected by syncthing whereas it detects other apps modifications.

When I speak of syncthing detection, it has nothing to do with a periodic scan, it should be android detecting file changes and notifying apps.

Nevertheless, when I create a notebook with orgzly, it is detected by syncthing.

Is it a bug ? It is a little annoying because I had to set 10 seconds periodic scans for syncthing in order for changes to be propagated in near real time.

Regards

[nevenz]

Are you using content://... repository or file:/storage/emulated/0/org?

[deb75]

Hi

I defined some repositories in the synchronization section of parameters. I chose "directory" and it is in the form content://... Should I use the other form ?

Thanks for your help

Regards

[nevenz]

I defined some repositories in the synchronization section of parameters. I chose "directory" and it is in the form content://... Should I use the other form ?

I think it might help in this case, although it's not a long-term solution due to Android 10 changes (scoped storage).

It would be helpful to know if that solves the issue in any case.

There have been reports about issues with Syncthing and modification times. Alhough it was the other way around so far - Orgzly not detecting changes as Syncthing updates of modification times were not visible by DocumentsProvider.

[smnthermes]

Isn't it better to directly read and write the files, just like Markor does?

[nevenz]

Isn't it better to directly read and write the files, just like Markor does?

Database is used primarily so data can be indexed for faster searching and navigation and as an abstraction so that multiple file formats could be supported.

[focusaurus]

I'm having a similar issue. I edit a file on a PC, syncthing syncs it to android, I confirm with a text editor the new version is synced to my phone, orgzly does a sync, but orgzly still shows the old content.

Workaround: delete the notebook in orgzly, but not the linked copy. It will immediately reappear with the correct new content.

[nevenz]

I'm having a similar issue. I edit a file on a PC, syncthing syncs it to android, I confirm with a text editor the new version is synced to my phone, orgzly does a sync, but orgzly still shows the old content.

You'll probably find last-updated time in content provider not updated by Syncthing. You could check it if you have an app that cab read it (like default "Files" app on some devices) or using adb.

[doak]

I have the very same issue like @deb75, using Orgzly v1.8.3 (fdroid) with a file based repository (i.e. no WebDAV) and Syncthing v1.7.0 (fdroid). (Android is quite old, Replicant 6.0.) I had similar issues with Nextcloud which was the reason trying out Syncthing.

I defined some repositories in the synchronization section of parameters. I chose "directory" and it is in the form content://... Should I use the other form ?

I think it might help in this case, although it's not a long-term solution due to Android 10 changes (scoped storage).

In fact that works like a charm. I am using file:///mnt/sdcard/<some-folder> which I entered manually, since the dialogue provides content:// URIs only (which seems to be the future if I have read it correctly).

Does that mean ContentProvider is buggy or used wrongly?

[JimBreton]

Got the same issues here, although on Android 11 (Pixel 3 XL), Orgzly 1.8.4. Tried with Syncthing and Dropbox, and using content:// and file:// specs, in both cases Orgzly does not detect that the underlying file (local repository) has changed.

At this point I think this is a known and accepted issue, just wanted to point out to other readers that the above workarounds may not work depending on circumstances. Seems no permanent resolution is available yet.

[nevenz]

Does that mean ContentProvider is buggy or used wrongly?

I don't think it's being using by Syncthing, so when using content:// in Orgzly, different data is compared.

Got the same issues here, although on Android 11 (Pixel 3 XL), Orgzly 1.8.4. Tried with Syncthing and Dropbox, and using content:// and file:// specs, in both cases Orgzly does not detect that the underlying file (local repository) has changed. At this point I think this is a known and accepted issue, just wanted to point out to other readers that the above workarounds may not work depending on circumstances. Seems no permanent resolution is available yet.

I'd say only Synching when using content:// could be expected not to work for all users. But other cases you mention should be working, or it's a bug. You're having issues even with Dropbox? Can you give some steps you're performing before you see an issue?

[JimBreton]

I'd say only Synching when using content:// could be expected not to work for all users. But other cases you mention should be working, or it's a bug. You're having issues even with Dropbox? Can you give some steps you're performing before you see an issue?

Just to clarify, the changes are only not detected when the app is idle -- i.e., everything works fine when I am modifying/refreshing in the mobile app as I have all of those switches turned on. IRL this is really only a problem if I modify entries using the widget or the persistent notification, as the app has not been triggered into syncing by any foreground activities. (My understanding was that background sync was not yet implemented hence the grayed-out switch in the Auto-sync options.)