wagoodman/dive · warning

unable to write to hash: %w

Error message

unable to write to hash: %w

What it means

Raised as a panic in getHashFromReader (dive/filetree/file_info.go:138) if h.Write on an xxhash.Digest returns an error. Go's xxhash Digest.Write never returns a non-nil error, so in practice this branch is unreachable defensive code.

Source

Thrown at dive/filetree/file_info.go:138

	return Modified
}

func getHashFromReader(reader io.Reader) uint64 {
	h := xxhash.New()

	buf := make([]byte, 1024)
	for {
		n, err := reader.Read(buf)
		if err != nil && err != io.EOF {
			panic(fmt.Errorf("unable to read file: %w", err))
		}
		if n == 0 {
			break
		}

		_, err = h.Write(buf[:n])
		if err != nil {
			panic(fmt.Errorf("unable to write to hash: %w", err))
		}
	}

	return h.Sum64()
}

View on GitHub (pinned to d6c691947f)

Solutions

1. Treat a report of this panic as a build-integrity question: confirm you are running unmodified dive and a stock xxhash dependency
2. If you forked getHashFromReader with a failing writer (e.g. a tee to disk), fix or remove the failing writer - xxhash itself cannot fail
3. Not actionable at the call site: there is no input that legitimately triggers it

When it happens

Trigger: Only reachable if the hash implementation is swapped for one whose Write can fail (a wrapping/tee writer with a failing downstream), or via memory corruption. With the vendored github.com/cespare/xxhash it does not occur.

Common situations: Effectively never seen in the wild. If reported, it usually indicates a modified fork of dive or a corrupted binary rather than a runtime condition.

Related errors

• unable to open file %q: %s
• unable to read file: %w
• could not add child node: '%s' (path:'%s')
• could not stack tree range: %w
• unable to read symlink %q: %s

AI-assisted analysis of wagoodman/dive@d6c691947f (2026-08-15). Data as JSON: /api/errors/6d5245cdc7987fd6. Report an issue: GitHub.