[FEAT] Sync: propagate updated attachments

[ltguillaume]

✅ Before submitting

• I searched existing issues and discussions
• This is one request (not multiple unrelated features)

💻 Target Platform

• Desktop
• Mobile
• Cloud / Sync / MCP
• Cross-platform

🧭 Area

• Inbox / review workflow
• Projects / areas / sections
• Search / filter
• Notifications / recurrence / calendar
• Sync / attachments
• UI / accessibility / i18n
• Release / distribution
• Other

🤔 Is your feature request related to a problem?

Currently, Mindwtr considers attaching files a one-off operation: even if you link to an external file, which is then synced, any updates to the original file get ignored.

💡 Proposed Solution

If the original file, either a linked attachment or a regular one, gets updated locally, propagate the changed file via sync.

• Save the modification timestamp as reference
• It might be good to save a hash of the file, too. At least after having opened the document via Mindwtr, it could check for changes, even if the modification timestamp hasn't changed.
• If the file has changed, up the revision number of the record and if sync is enabled, re-upload the file
• If a synced device sees the revision number of an attachment is upped, re-download the file

[dongdongbh]

Accepted — this is the follow-up we discussed in #1001, and it's worth doing. Attachments today are snapshot-at-attach-time (upload happens once, keyed by the record's identity), and treating them as living files matches what people expect, especially for linked files.

One design decision up front, since it shapes everything: no file watchers. OS-level monitoring of user-picked external paths is a poor fit across platforms (no SAF equivalent on Android, watcher lifecycles across restarts, battery). Detection will instead be check-on-touch: the attachment pre-pass that every sync cycle already runs stats each local file for existence — it will additionally compare modification time and size against values stored on the record, with a content hash as the confirming check (a hash field already exists on the record), and re-check after a file is opened through Mindwtr. That covers your proposal's mechanics — stored mtime as reference, hash to catch content changes, revision bump on change, re-download on other devices — without any standing monitors.

The invariants the implementation has to carry:

• Loop safety: a fresh download gets a new local mtime, so the post-download stat must be recorded immediately — otherwise every device re-detects a "change" forever. A second sync with nothing changed must be a byte-for-byte no-op.
• Downloads are write-temp-then-rename, so a connection cut mid-download can't leave a truncated file that then re-uploads as the "new" content.
• Concurrent edits of the same file on two devices resolve last-writer-wins on the whole file — there is no content merge. Stating this openly, same as the sync docs do for the data file.
• The new synced fields (content revision, hash, recorded mtime) must merge cleanly against older clients that don't know them.
• On replicator backends (Syncthing, Nextcloud, rclone chains), every re-upload becomes a new version in the platform's history — that storage churn is inherent to the feature.

Two scope notes: detection of linked (external-path) attachments is effectively desktop-first — mobile can't freely re-read arbitrary external paths, so phones mostly participate on the re-download side. And this doesn't conflict with the encryption design in #1056; the comparison model decided there (existence plus metadata from the synced document) stays correct with or without this feature.

It's queued behind the current open work rather than scheduled, so no timeline promise — but the design above is settled enough that a PR following it would be very welcome if you want it sooner.

[dongdongbh]

Add a fix 370b74f.

Works as discussed above: each sync cycle compares an attached file's modification time and size against what was last synced (hash-confirming before anything re-uploads), bumps the content revision, re-uploads to the same key, and other devices re-download — with the post-download stat recorded immediately so an unchanged second cycle is a byte-for-byte no-op. Detection covers linked external files on desktop; phones re-download everywhere and detect edits inside the app's own attachment storage on File Sync, WebDAV, and iCloud — the mobile Dropbox and self-hosted paths still use their own transfer loops and will pick up detection in a follow-up. Concurrent edits of the same file resolve whole-file last-writer-wins, as stated.

Please test this in the next release and let us know if it resolves the issue.