spacedriveapp/spacedrive · error · anyhow::Error

Final checksum mismatch

Error message

Final checksum mismatch

What it means

With verify_checksum enabled, the whole-file blake3 hex of everything written did not equal the sender's final_checksum (strategy.rs:705-711). The received file is not byte-identical to what the sender hashed: the source changed during the transfer, chunks were written out of order, or versions hashed different byte ranges. The partial file is deleted. Note the code only warns when final_checksum is empty — this error requires a non-empty mismatched checksum.

Source

Thrown at core/src/ops/files/copy/strategy.rs:711

						));
					}

					// Verify final checksum if enabled
					if verify_checksum {
						if let Some(h) = hasher.take() {
							let calculated = h.finalize();
							let calculated_hex = calculated.to_hex().to_string();

							if final_checksum.is_empty() {
								// Warn when checksum verification enabled but no checksum provided
								ctx.log("Warning: checksum verification enabled but remote did not provide checksum".to_string());
							} else if calculated_hex != final_checksum {
								error!(
									"Final checksum mismatch: expected {}, got {}",
									final_checksum, calculated_hex
								);
								let _ = fs::remove_file(&final_dest_path).await;
								return Err(anyhow::anyhow!("Final checksum mismatch"));
							}
						}
					}

					transfer_completed = true;
					ctx.log(format!(
						"PULL transfer completed: {} bytes received",
						total_bytes_received
					));
					break;
				}
				crate::service::network::protocol::file_transfer::FileTransferMessage::TransferError {
					message,
					..
				} => {
					// Clean up partial file
					let _ = fs::remove_file(&final_dest_path).await;
					return Err(anyhow::anyhow!("Transfer error: {}", message));

View on GitHub (pinned to 6dfeccf211)

Solutions

1. Retry once the source file is no longer being modified on the remote
2. Quiesce/close the file on the remote before pulling it
3. Verify both devices run the same core version so checksum scope matches
4. If it persists on a static file, log both hex digests and compare per-chunk checksums to localize the divergence

match remote_strategy.execute_pull(ctx, &src, &dst).await {
    Ok(n) => Ok(n),
    Err(e) if e.to_string() == "Final checksum mismatch" => {
        // source likely changed mid-transfer; wait for quiescence and retry once
        tokio::time::sleep(std::time::Duration::from_secs(5)).await;
        remote_strategy.execute_pull(ctx, &src, &dst).await
    }
    Err(e) => Err(e),
}

When it happens

Trigger: Source file modified on the peer while the pull was in flight (sender hashed before or after a change); out-of-order chunk writes; mixed versions computing checksums over different scopes.

Common situations: Pulling log files or actively edited documents; the same document open in an editor on the remote; mid-upgrade device fleets.

Related errors

• Chunk {} checksum mismatch
• Byte count mismatch: expected {}, got {}
• Failed to calculate checksum: {}
• Pull request rejected: {}
• Unexpected response to pull request

AI-assisted analysis of spacedriveapp/spacedrive@6dfeccf211 (2026-08-16). Data as JSON: /api/errors/b6513d4cbe37d05c. Report an issue: GitHub.