gastownhall/beads · error

reading remote store %s: %w

Error message

reading remote store %s: %w

What it means

clearDoltFileStore removes the contents of a native Dolt file-store directory (keeping the directory itself) so a follow-up push can rebuild it, and this error wraps an os.ReadDir failure on that directory. The caller has already verified a manifest exists, so the directory existed moments earlier — the failure is almost always permissions or the directory disappearing mid-operation.

Source

Thrown at cmd/bd/dolt_remote_reset_data.go:178

	base := os.Environ()
	merged := githooksenv.AppendParameter(githooksenv.Extract(base), githooksenv.NoHooksParam)
	env := make([]string, 0, len(base)+1)
	prefix := githooksenv.ParametersEnv + "="
	for _, e := range base {
		if !strings.HasPrefix(e, prefix) {
			env = append(env, e)
		}
	}
	return append(env, prefix+merged)
}

// clearDoltFileStore removes the contents of a native Dolt file-store
// directory, keeping the directory itself so the follow-up push can rebuild
// the store in place. The caller has already verified a manifest is present.
func clearDoltFileStore(dir string) error {
	entries, err := os.ReadDir(dir)
	if err != nil {
		return fmt.Errorf("reading remote store %s: %w", dir, err)
	}
	for _, entry := range entries {
		if err := os.RemoveAll(filepath.Join(dir, entry.Name())); err != nil {
			return fmt.Errorf("clearing remote store %s: %w", dir, err)
		}
	}
	return nil
}

var doltRemoteResetDataYes bool

var doltRemoteResetDataCmd = &cobra.Command{
	Use:   "reset-data <name>",
	Short: "Replace a remote's data plane in place after a history squash",
	Long: `Replace a Dolt remote's stored data with a fresh copy of local HEAD.

After a history squash (see the History Bloat recovery runbook), a plain
'bd dolt push --force' re-points the remote's refs but deletes nothing:

View on GitHub (pinned to 71377f2769)

Solutions

1. Fix ownership/permissions on the store directory so the running user can list and delete its entries
2. Ensure no concurrent process (Dolt server, another bd run) is touching the store; stop it and retry
3. Verify the filesystem is writable and not mounted read-only
4. If the store was deleted mid-run, re-run the command from the start so classification re-runs

Example fix

// before
$ ls -ld /srv/dolt/repo  # owned by doltserver
// after
$ sudo chown -R $USER /srv/dolt/repo && bd dolt remote reset-data origin

if info, err := os.Stat(dir); err != nil || !info.IsDir() {
    return fmt.Errorf("store %s missing or not a directory", dir)
}
if !writable(dir) { return fmt.Errorf("store %s not writable", dir) }

if err := clearDoltFileStore(dir); err != nil {
    // likely transient or permission issue: stop concurrent writers, then retry once
    return fmt.Errorf("store left partially cleared; re-run reset-data: %w", err)
}

When it happens

Trigger: During bd dolt remote reset-data on a classified Dolt file store, os.ReadDir(dir) fails after the manifest check: permission denied, the directory was removed by a concurrent process, or an I/O error.

Common situations: Remote store owned by another user/root (e.g. created by a Dolt server); concurrent reset or cleanup job deleting the store between classification and clearing; filesystem mounted read-only.

Related errors

• inspecting remote target %s: %w
• dolt path is not executable
• creating .bd-dolt-ok marker: %w
• failed to remove Dolt database: %w
• remote target %s is non-empty but is neither a bare git repo

AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30). Data as JSON: /api/errors/52bfcfbacef90fea. Report an issue: GitHub.