0.1.36

Four fixes from extending the sync re-verification to the delete, rename, preferences and attachment paths.

Every delete was echoed back as a phantom file

Applying a delete from the change feed removed the file without telling the loop protection, and the delete handler never consulted it at all — deletes were simply exempt. So the delete Obsidian fires for the plugin's own removal got re-sent as a fresh one. By then the local record is gone, so it carried no file id, and a commit without one always creates a new file.

The result: every device that received any delete silently committed a phantom file, version, change event and R2 blob — each billed against your storage and never reclaimed. The same ran behind every rename's old-path cleanup, which is part of why change feeds grew fast enough to hit the paging bug fixed in 0.1.35.

Deleting a file then recreating it resurrected the old one

The committed delete left the local record behind, so a file later created at that path inherited the dead file's identity and committed as another version of it instead of as a new file.

Preference bundles could write outside the config folder

applyPreferencesBundle wrote whatever paths a bundle contained. The exclusion protecting this plugin's own folder is a string comparison, so plugins/other/../synora-sync/data.json walked straight past it, and .. or an absolute path escaped .obsidian/ entirely — defeating the rule the whole feature is built on, that one device's identity is never overwritten by another's.

Attachments no longer thrash data.json

Queued operations stored the entire encrypted file inline, in the blob Obsidian rewrites in full on every write — so each queue change re-serialised every other pending attachment too, in memory.

	before	after
20 photos at 3MB	1.56 GB written	0.1 MB
5 PDFs at 25MB	0.81 GB written	0.0 MB

Payloads now live one file each under the plugin's own folder, written once and deleted once. Anything queued by an older version is migrated on upgrade rather than dropped, so un-synced edits survive the update. Files over the upload cap are now reported up front instead of being encrypted and written to disk before the server rejects them.

No backend change — works against the already-deployed server.