{"version":"2.1.248","anchor":"cloud-directory-sync-handles-starting-from-an-empty-working-","canonical_anchor":"cloud-directory-sync-handles-starting-from-an-empty-working-","heading":"Cloud directory sync handles starting from an empty working directory","tier":"notice","area":"File Sync","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/cloud-directory-sync-handles-starting-from-an-empty-working-","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Cloud directory sync handles starting from an empty working directory\n\nCloud sessions that start before your files arrive now say whether files are coming or sync stopped.\n\n**What**\n\nCloud sessions that begin before your files have arrived now have a defined path: sync records that it started empty, checks out the first upload from your machine, and if that fails it turns sync off with a stated reason. New messages tell the model whether files are still coming, arrived late, or that sync stopped and work must continue on your own machine.\n\n**Details**\n\n- Disarm reasons include: the directory was not empty, the first uploaded object could not be read, the bundle failed verification, the container was recreated, or the git checkout failed.\n- Adds a log point for an unread empty-start marker, `dir_sync_git_empty_start_flag_unread`.\n- Part of the git-based cloud directory sync; no separate flag turns this path on or off.\n\n**Evidence**\n\n`Directory sync could not check in before this turn began, and this working directory is EMPTY.`\n\n- Area: File Sync\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5"}