sboesen / remotely-sync

fork of remotely-save with security upgrades
Apache License 2.0
180 stars 7 forks source link

[Feature Request]: Detect remote changes in a lightweight fashion and sync if changes #47

Open sboesen opened 7 months ago

sboesen commented 7 months ago

What feature are you suggesting?

See comment.

Actually a good point to bring up is that if you leave obsidian idle and then edit say on your phone, then the vault won't sync up to date on desktop until a file change is made. So in that case it's best for me to manually sync or set autorun to like 10 minutes. Maybe there could a sync on idle return feature, but I'm not entirely sure how that could be done. Maybe by checking if obsidian becomes refocused?

We could cheaply (energy/network usage) check if the modification time for the manifest file is later than our last sync, and if so, check for a sync. This manifest modified check would be cheaper than a full sync.

Not sure I'll implement this, but more of a brainstorming issue.

What remote cloud services are you using, or suggesting adding the feature to?

No response

Ensure no sensitive information

kadisonm commented 7 months ago

By the manifest file, do you mean the plugin's manifest on the remote service?

kadisonm commented 7 months ago

Just by my understanding, doesn't the manifest only change when the plugin is updated (version number). Wouldn't we want to check data.json, since that modifies every time we sync? And also, if we are checking for remote changes, wouldn't the .obsidian folder have to be synced, what about with syncing .obsidian is disabled?

I've probably misunderstood since I don't entirely know how the syncing process works. If we are checking the plugin's local files then those won't update until they are synced right, so wouldn't you have to check on the remote service?

sboesen commented 7 months ago

We call the manifest both manifest.json, where you're right, and the manifest which is stored encrypted containing the list of deleted files. This is uploaded on first sync and currently used to determine if the user has unencrypted files (in addition to not setting a password).

Definitely confusing using the term for both

kadisonm commented 7 months ago

Ahh that makes so much more sense. So I'm assuming the manifest file is modified on sync?

This manifest modified check would be cheaper than a full sync.

Sounds like a good idea, are there any drawbacks to accessing it on the remote service routinely?

sboesen commented 7 months ago

Can't be worse than doing a full sync every few seconds! I think we can modify auto sync to use this behavior, and sync on save to stay the same.

So I'm assuming the manifest file is modified on sync?

Yes but might need to change the plugin so it isn't modified if there is nothing to sync. Not sure.

kadisonm commented 7 months ago

Can't be worse than doing a full sync every few seconds! I think we can modify auto sync to use this behavior, and sync on save to stay the same.

That's true.

I think we can modify auto sync to use this behavior

I think that would be great, might also want to make a legacy version of the auto sync though for people who want to be extra sure. Personally I'd just rely on auto sync and sync on save.

Yes but might need to change the plugin so it isn't modified if there is nothing to sync. Not sure.

We could actually combine some of this behaviour with #43. We will need to track sync history so a SyncHistory.json or similar could serve a double purpose. With the date and (success/error) added on each sync. In the case people don't want sync history then it can just overwrite the first item and I think it will still be marked as modified. 🤔

kadisonm commented 6 months ago

Does each cloud service support checking modification times? If not we might have to make a standard way of checking. Could always download a really small file but not sure if that would really be light weight each second or so.

This should probably be done in conjunction with fixing how deleted files are managed.

sboesen commented 6 months ago

I think most providers do, worth confirming before going too deep on implementation though.

sboesen commented 6 months ago

Thanks to @kadisonm this should be fixed in 0.4.33!