<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Transfer on BitSpeed.org</title>
    <link>https://bitspeed.org/tags/transfer/</link>
    <description>Recent content in Transfer on BitSpeed.org</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 20 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://bitspeed.org/tags/transfer/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>BitSpeed Transfer Case Study Resumes a Killed 256 MiB Upload</title>
      <link>https://bitspeed.org/bitspeed-transfer-case-study-resumes-a-killed-256-mib-upload/</link>
      <pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bitspeed.org/bitspeed-transfer-case-study-resumes-a-killed-256-mib-upload/</guid>
      <description>&lt;p&gt;The test is blunt. Start a file transfer, kill both ends with SIGKILL partway through, start them again and see what happens. No clean shutdown, no chance to save state on the way out. If the tool&amp;rsquo;s bookkeeping is honest, the restart should know exactly which pieces arrived and send only the rest.&lt;/p&gt;&#xA;&lt;p&gt;This run used the released Linux amd64 build of Transfer 0.1.0, downloaded from the release and checked against its SHA256SUMS. The file was 256 MiB of random data called video.mov, split into 256 chunks of 1 MiB. Sender and receiver ran on the same machine over loopback.&lt;/p&gt;</description>
    </item>
    <item>
      <title>BitSpeed Transfer Resumes Interrupted File Transfers From Verified Chunks</title>
      <link>https://bitspeed.org/bitspeed-transfer-resumes-interrupted-file-transfers-from-verified-chunks/</link>
      <pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bitspeed.org/bitspeed-transfer-resumes-interrupted-file-transfers-from-verified-chunks/</guid>
      <description>&lt;p&gt;An interrupted transfer should not make you guess which bytes arrived. BitSpeed Transfer 0.1.0 starts with a saved snapshot, splits it into hashed chunks and asks the receiver to substantiate its progress after restart. Repeat the send command with the same snapshot and ID, and it sends the chunks still missing. The original source can stay out of the recovery path.&lt;/p&gt;&#xA;&lt;p&gt;Completion has a separate gate. The receiver assembles the file, checks its full digest and publishes a fixed destination without replacing an unrelated file. A retained witness and stable receipt let the next request verify that same output after a lost final response. The sender checks the receipt against its manifest and saves it locally before saying transferred true. A staging result alone is not enough.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How BitSpeed Inspect and Transfer Were Tested</title>
      <link>https://bitspeed.org/how-bitspeed-inspect-and-transfer-were-tested/</link>
      <pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bitspeed.org/how-bitspeed-inspect-and-transfer-were-tested/</guid>
      <description>&lt;p&gt;Each tool makes one main promise, and the tests go after that promise first. Inspect promises to explain where observed request time went without inventing a cause. Transfer promises that an interrupted file transfer resumes from verified pieces and ends in one complete, checked file. Happy paths are covered too. They just aren&amp;rsquo;t where the effort went.&lt;/p&gt;&#xA;&lt;p&gt;Every push to main runs the full suite on Linux and macOS: formatting, go vet, race-enabled tests, both command builds and smoke checks against the built executables. The outcomes are written to &lt;a href=&#34;https://github.com/softdevstudio/bitspeed/tree/main/test/results&#34;&gt;recorded results&lt;/a&gt; with the Go version, platform and a fingerprint of the source tree.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
