{"version":"2.1.246","anchor":"a-third-file-sync-transfer-path-direct-is-built-on-both-side","canonical_anchor":"a-third-file-sync-transfer-path-direct-is-built-on-both-side","heading":"A third file-sync transfer path, \"direct\", is built on both sides but unreachable","tier":"soon","area":"File Sync","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246\/e\/a-third-file-sync-transfer-path-direct-is-built-on-both-side","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246","markdown":"### A third file-sync transfer path, \"direct\", is built on both sides but unreachable\n\nFile sync gained a third \"direct\" transfer path through a file store, but it never runs.\n\n**What**\n\nFile syncing gained a third way to move file contents, called `direct`, which uploads and downloads through a file store endpoint instead of inline. Both the sending and receiving halves exist, with size and deadline options, but the client that would drive it defaults to null and nothing in this build supplies one, so the path never runs.\n\n**Details**\n\n- Tuning options exist as `directMinBytes`, `directInboundMaxBytes` and `directDeadlineMs`.\n- Even with a client supplied, the path only activates if the server answers that it offers the lane.\n- The record of how each file was transferred changed from a fixed two-value choice to a free string of up to 32 characters; anything unrecognised becomes `\"unknown\"`, and a record marked `\"unknown\"` is refused on write.\n- Three new server refusal codes accompany it: `synced_file_direct_upload_unavailable`, `synced_file_direct_download_unavailable` and `synced_file_lane_denied`.\n\n**Evidence**\n\n`synced_file_direct_upload_unavailable`\n\n- Area: File Sync\n- Tier: Nothing to try yet\n- Useful: 2\/5\n- Signal: 0\/5\n- Present in the build but not switched on"}