Files SDK 1.6 adds transfer() streaming and byte-range downloads

• Files SDK 1.6 shipped with a new cross-provider transfer() primitive that, according to haydenbleasel's transfer() post, streams objects between providers instead of buffering whole large files in memory.
• Byte-range downloads landed alongside it, and haydenbleasel's byte-ranges post framed the feature around partial reads, resumable flows, and media UIs that only fetch the bytes they need.
• the Files SDK v1.6 release post described the release as the project's biggest so far and grouped it around observability, big files, and cross-provider workflows.
• The official docs linked from the transfer() announcement and the byte-range announcement give Files SDK a much more concrete story for storage migration and large-object access than earlier upload and download wrappers alone.

You can jump straight to the transfer feature docs, the byte-range download docs, and the v1.6 release post, which is notable mostly because it ties the two features together under a bigger push into large-file handling and observability.

The headline addition is transfer(), which haydenbleasel's transfer() post says can stream an object from one provider to another. The examples in that post are concrete: moving from S3 to R2, re-homing a prefix, and migrating storage without holding the entire file in memory.

That makes this a storage-migration primitive, not just another upload helper. The linked transfer feature docs suggest Files SDK is trying to own the copy path between providers, where large objects usually turn naive read-then-write code into a memory problem.

Byte-range support landed on downloads in the same release. haydenbleasel's byte-ranges post calls out three immediate use cases:

• Partial reads for large files
• Resumable flows
• Video-player style interfaces that request only the needed bytes

The linked download API docs matter because range requests are one of those features that changes what kind of product can sit on top of a storage abstraction. Once a download API can serve slices instead of the whole object, media scrubbing, restartable clients, and file inspection workflows stop looking like awkward edge cases.

the release post says Files SDK 1.6 is its biggest release so far and summarizes it in three buckets:

• Observability
• Big files
  n- Cross-provider workflows

Only two of those buckets are spelled out in the evidence here, but they line up cleanly with the shipped features. transfer() covers the cross-provider story, while byte ranges covers one part of the big-file story. The observability piece is the new fact in the release framing, even if the tweet evidence here does not break out the specific instrumentation yet.