File sync gained a third "direct" transfer path through a file store, but it never runs.
Both halves of a direct file transfer path are built, but the client driving it defaults to null and nothing supplies one.
What's wrong with this entry?
File 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.
- Tuning options exist as
directMinBytes,directInboundMaxBytesanddirectDeadlineMs. - Even with a client supplied, the path only activates if the server answers that it offers the lane.
- 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. - Three new server refusal codes accompany it:
synced_file_direct_upload_unavailable,synced_file_direct_download_unavailableandsynced_file_lane_denied.
synced_file_direct_upload_unavailable
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.