Sync API timing problems

This relates to #621 but is much more specific and probably better presented as a stand alone issue.
I am building a sync between tomboy-ng and Nextcloud Notes. The Tomboy standard relies on meta data stored in xml and I am finding difficulties working with NextCloud which does not.

Unless there is a way around this issue (that I cannot see) it is probably also causing problems with other applications using the API.

Because the 'modified' time returned via the API does not respect things like changes to a note's name, I must use the pruneBefore parameter to a GET to determine what notes have changed on NextCloud. So, the process is to request a list of notes from NextCloud and record its time stamp (LastSyncTime). We work out what needs to happen and download and upload as necessary. That takes some time so we end up with uploaded notes getting NextCloud time stamps later than the recorded LastSyncTime.

If no changes are made at either end and another sync is run, the uploaded notes (remember they were uploaded after the LastSyncTime) are seen as new or changed and will be downloaded. Putting aside the network traffic issue, they will then get a wrong LastChangeDate and will trigger a false 'clash' if the user does make a change locally between those syncs. Confusion and potential data loss.

A similar problem happens if new/changed notes are uploaded before taking a pruneBefore GET.

Is there a way to avoid this that I have not spotted ? It seems to me that the difficulties will be with us unless NextCloud Notes finds a way to maintain the necessary meta data outside of the note files them selves.

NextCloud seems to be maintaining two time stamps, the one associated with 'modified' and the one that is used by pruneBefore. I'm guessing that pruneBefore uses the file's file system date stamp, just where does 'modified' time come from ? Personally, I believe that 'modified' should mean any modification including the note name !

Davo

No files, tests, or entry points are named. Reproduce the sync sequence involving note renames, uploads, LastSyncTime, and GET with pruneBefore, then trace how the API supplies each timestamp; done means the timing behavior is resolved or clearly specified without false changes or conflicts.