{"version":"2.1.246","anchor":"org-memory-sync-adopts-an-identical-remote-file-instead-of-f","canonical_anchor":"org-memory-sync-adopts-an-identical-remote-file-instead-of-f","heading":"Org memory sync adopts an identical remote file instead of failing","tier":"notice","area":"Memory","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246\/e\/org-memory-sync-adopts-an-identical-remote-file-instead-of-f","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246","markdown":"### Org memory sync adopts an identical remote file instead of failing\n\nShared memory sync adopts an identical remote file instead of erroring on the collision.\n\n**What**\n\nWhen syncing shared memory files, a create that collides with an existing remote path now re-reads that file: if its contents hash matches what was about to be uploaded, the existing file is adopted and the collision is logged rather than treated as an error.\n\n**Details**\n\n- Creates now declare that the path must not already exist, making the collision explicit.\n- A collision where the contents differ still raises the error.\n- Update failures caused by a stale file id are rechecked by re-reading the file rather than by a bare existence probe.\n\n**Evidence**\n\n`multi-store-sync[`\n\n- Area: Memory\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5"}