{"version":"2.1.247","anchor":"memory-files-emptied-locally-are-restored-on-pull","canonical_anchor":"memory-files-emptied-locally-are-restored-on-pull","heading":"Memory files emptied locally are restored on pull","tier":"notice","area":"Memory","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.247\/e\/memory-files-emptied-locally-are-restored-on-pull","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.247","markdown":"### Memory files emptied locally are restored on pull\n\nShared memory files you accidentally emptied are refilled from the team copy on pull.\n\n**What**\n\nPulling team or org memory now notices when a file's recorded content is the empty-file hash while the shared copy has real content, and rewrites the file when the local one is genuinely a stale empty file, judged by being 0 bytes and older than a threshold.\n\n**Details**\n\n- Fetched content is re-hashed and mismatches against the recorded hash are counted.\n- Deletion handling runs the same empty-file check before telling you your local copy was kept.\n- The sync result gained counts of hash mismatches and restored empty files.\n- The concurrent-write log no longer claims that situation only occurs on a first pull.\n\n**Evidence**\n\n`team_memory_multistore_concurrent_write_preserved`\n\n- Area: Memory\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}