Hi. I am running Joplin on my Android phone and a Linux desktop. I have set the Android client to use filesystem sync into a folder called ‘Joplin’ and I then use syncthing to sync that folder to the Linux box.
I did the same thing on the Linux client - file system sync, pointing to the synchronised folder on my hard drive.
If I add a new note on either client, I can see that the .md containing the note is synched to both copies of the Joplin folder but notes created on one device do not appear on the other, and vice-versa.
I feel sure I have missed something obvious but have no idea what.
1 Like
temp
28 June 2020 14:56
2
Did you ever figure this out? I have a similar issue…
Nope! Have installed a basic Nextcloud instead. Would love to know where I went wrong
temp
13 July 2020 12:11
4
This might sound silly, but have you checked the FS permissions? My symptoms were the same on a shared NTFS partition until I realized linux just wasn’t mounting it with write permissions. IIRC Android’s FS has a similar thing going on by default.
Permissions seem fine to me. All the files are synching (I can open them using other apps) but Joplin never seemed to see them
Exact same issue here. Looking forward for a solution.
1 Like
Finn
15 June 2021 07:50
7
Hi there,
1 Like
An issue has been opened for this on Github.
opened 07:11PM - 15 May 22 UTC
bug
sync
medium
When syncing to the file system, new files with a timestamp older than the last … sync timestamp get silently ignored (instead of being pulled into Joplin).
This situation arises for me because I run Joplin on my PC and phone, have them both sync to the filesystem and then use [syncthing](https://syncthing.net/) to sync the two. syncthing maintains file last-modified metadata across devices, meaning that if my mobile device is not busy syncing (could be that syncing is off, I'm out of network range, off wifi, etc) and I add a note, wait a day and then let it sync, then the file on my PC will have a creation date of right now and a last-modified date that is a day in the past. Joplin ignores it.
## Environment
Joplin version: 2.7.15 (Although this has been happening for at least a year, I updated recently and I *think* I was on 2.3.6 before that)
Platform: Desktop, Windows 10 x64 21H2/19044
## Steps to reproduce
1. Set joplin to sync to the filesystem and ensure it is all synced up.
2. Close Joplin
3. Create a new note file (I copied an existing one and changed the name & ID in the file to a new hash)
4. Set the file's last-modified time to before your last Joplin sync
* e.g in powershell: `(Get-Item "c6989cfc4d4d9114591431119fe5e8a5.md").LastWriteTime=("15 May 2022 19:38:00")`
5. Open Joplin & sync
6. See that it does not pull in the new file
## Thoughts following my own short investigation into the synchronisation code
I've looked through the sync code in Joplin and I see it is relying entirely on the last-modified time of the file. In particular it will ignore any file with a timestamp older than Joplin's last sync time *even if the file is unknown to Joplin*. It seems to me that Joplin should instead read in new files even if they're older than the last sync time but there may well be other factors that I'm not aware of. I know little about the filesystem format but at the very least Joplin would need to check the contents of each new file to know what its reading in (my local instance has 200 notes but >500 files, some of which appear to be recordings of edits? Presumably these contains data from tables in the sqlite DB other than the "notes" table?)
Admittedly the same problem can happen with file edits. This is more difficult to resolve since you can't use the existence of the file as proof that a sync is needed. In that case, you might be able to use the file-specific sync time (in the sync_items table, assuming that actually contains what the name suggests) to do a somewhat better job, but short of hashing the file contents (which would be very robust but also far slower than checking file times and obviously problematic on all of the non-filesystem sync targets, possibly worth doing only for the filesystem sync target?) I'm not sure there's a great solution for that case. If the conclusion is that this behaviour is a problem then maybe solving the new-file case is at least a good start?
I can see about changing my non-joplin file-sync setup so that the file timestamps are updated when the file syncs (which would prevent this issue from happening to me in the first place) but that might not be as easy as one might hope and would only solve the problem with my particular setup (other file-system setups may run into the same issue).
This could possibly be the related to #5099 and #6346