Make it work with remotely-save plugin

[xplosionmind]

When using remotely-save, the update time of every file and folder is changed.

This should not happen: the updated time should be changng only when files are opened in Obsidian.

[xplosionmind]

Addendum: the update date is changed even if there are no actual changes to the file, and the change occurs just upon opening the file and the editor. It should not be so.

[beaussan]

I have changed the way the update time is calculated to reflect obsidian own's update time, so from now on, if obsidian has a newer update time, the header will reflect it

[beaussan]

I have introduced a new experimental system to handle this kind of syncs, feel free to try out the experimental feature ! https://github.com/beaussan/update-time-on-edit-obsidian/releases/tag/2.4.0 :tada:

(the only reason it's marked as experimental is that I didn't test it with vault bigger than 10k files, and it may miss updates)

[geerteltink]

@beaussan is it possible to use the internal IndexedDb to store the hashes? Adding them to the data.json file causes a lot of merge conflicts in case you chose to sync plugins with obsidian sync.

2023-11-05 07:20 - Connecting to server
2023-11-05 07:20 - Connection successful. Detecting changes...
2023-11-05 07:20 - Server pushed [xxx] inbox/2023-11-04.md
2023-11-05 07:20 - Server pushed [xxx] .obsidian/core-plugins.json
2023-11-05 07:20 - Server pushed [xxx] .obsidian/core-plugins-migration.json
2023-11-05 07:20 - Server pushed [xxx] .obsidian/plugins/update-time-on-edit/data.json
2023-11-05 07:20 - Downloading file inbox/2023-11-04.md
2023-11-05 07:20 - Downloading complete inbox/2023-11-04.md
2023-11-05 07:20 - Accepted inbox/2023-11-04.md
2023-11-05 07:20 - Downloading file .obsidian/core-plugins.json
2023-11-05 07:20 - Downloading complete .obsidian/core-plugins.json
2023-11-05 07:20 - Accepted .obsidian/core-plugins.json
2023-11-05 07:20 - Downloading file .obsidian/core-plugins-migration.json
2023-11-05 07:20 - Downloading complete .obsidian/core-plugins-migration.json
2023-11-05 07:20 - Accepted .obsidian/core-plugins-migration.json
2023-11-05 07:20 - Downloading file .obsidian/plugins/update-time-on-edit/data.json
2023-11-05 07:20 - Download cancelled because file was changed locally. Will try again soon. .obsidian/plugins/update-time-on-edit/data.json
2023-11-05 07:20 - Merging conflicted file .obsidian/plugins/update-time-on-edit/data.json
2023-11-05 07:20 - Merge successful .obsidian/plugins/update-time-on-edit/data.json
2023-11-05 07:21 - Fully synced
2023-11-05 07:24 - Connecting to server
2023-11-05 07:24 - Connection successful. Detecting changes...
2023-11-05 07:24 - Fully synced

[beaussan]

Unfortunately, using the IndexedDb would not work, since the goal of this cache is to be distributed across at least two devices.

The whole idea of the cache is, when a file has been detected to have been updated, check if the hash is the same. If they are the same, then, it could have been a sync trigger or a file system one that triggered. If the cache would be in the IndexedDb, then it would only live in one Obsidian instance, and thus, fallback into the previous system.

See flow with current setup :

See flow with using IndexedDb :

The only two ways I know that could work in this situation are :

• have a hash store in the plugin settings (like the Readwise plugin is using for example)
• have the hash stored in a frontmatter in the file itself. I discarded this option because it will introduce noise and a lot of possible "Note title" has been modified externally, merging changes automatically.

I'm open to suggestion to have another possible way to handle this

[geerteltink]

Thanx for the explanation and schemas @beaussan. It makes sense like this. Using frontmatter could be a solution, but would cause a lot of noise as you mention.

[gmmazza]

Hello. I find that creationDate YAML field is changed in the remote locations to the time it was synced for the first time. Maybe you could set that field is not changed to ctime if already in the YAML.