{"version":"2.1.246","anchor":"directory-sync-can-upload-and-download-files-directly-to-a-f","canonical_anchor":"directory-sync-can-upload-and-download-files-directly-to-a-f","heading":"Directory sync can upload and download files directly to a filestore","tier":"internal","area":"Cloud Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246\/e\/directory-sync-can-upload-and-download-files-directly-to-a-f","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246","markdown":"### Directory sync can upload and download files directly to a filestore\n\nLarge sync payloads can now go straight to a filestore, falling back if the server refuses.\n\n**What**\n\nDirectory sync gains a third way to move data alongside the existing row and file carriers: a `direct` lane that uploads content straight to a filestore, addressed by a sha256 of the content and keyed off the session id. There is no client flag for it. The client offers it for outbound payloads above a minimum size, and a server replying `unsupported` marks the lane refused and puts it on a cooldown before it is tried again, falling back to the row lane meanwhile.\n\n**Details**\n\n- New client calls begin an upload, commit it, and fetch a download descriptor against per-session synced_file endpoints, returning a filestore url, id and JWT plus an upload path.\n- Transfers are resumable: `expired` or `not_found` responses trigger a retry, and inbound transfers have their own size cap.\n- Repeated non-429 failures back the lane off; a server that never implements it costs one attempt per cooldown window.\n- The lane is wired live at both places directory sync builds its transport, so whether it does anything is decided entirely by the server.\n\n**Evidence**\n\n`\/v1\/code\/sessions\/${n}\/synced_file\/uploads\/commit`, `dir-sync: direct commit refused: the declared name holds other bytes`\n\n- Area: Cloud Sessions\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}