moonD4rk/HackBrowserData · warning

copy %s: %w

Error message

copy %s: %w

What it means

Acquire wraps failures copying SQLite WAL (-wal) or SHM (-shm) companion files with "copy %s: %w" (suffix is "-wal" or "-shm"). The main database copied fine, but copying its sidecar files failed, which can leave the staged database inconsistent — recent transactions living only in the WAL will be missing when the copy is opened.

Source

Thrown at filemanager/session.go:65

		// On other platforms, return the original error directly.
		if runtime.GOOS != "windows" {
			return fmt.Errorf("copy: %w", err)
		}
		if err2 := copyLocked(src, dst); err2 != nil {
			return errors.Join(
				fmt.Errorf("copy: %w", err),
				fmt.Errorf("locked copy: %w", err2),
			)
		}
	}

	// Copy SQLite WAL/SHM companion files if present
	var walErrs []error
	for _, suffix := range []string{"-wal", "-shm"} {
		walSrc := src + suffix
		if isFileExists(walSrc) {
			if err := copyFile(walSrc, dst+suffix); err != nil {
				walErrs = append(walErrs, fmt.Errorf("copy %s: %w", suffix, err))
			}
		}
	}
	return errors.Join(walErrs...)
}

// Cleanup removes the session's temporary directory and all its contents.
func (s *Session) Cleanup() {
	os.RemoveAll(s.tempDir)
}

View on GitHub (pinned to 0503d04d7a)

Solutions

  1. Retry the acquisition — WAL sidecars are transient; after a checkpoint the main DB may be self-contained.
  2. Close the browser first so the WAL is checkpointed and the sidecars become readable or disappear.
  3. Treat the extracted copy as potentially stale if the WAL could not be copied: verify expected rows exist before decrypting.
  4. Check disk space and destination writability for the dst+suffix files.

Example fix

// before
if err := s.Acquire(dbSrc, dbDst, false); err != nil {
    return err
}
// after
if err := s.Acquire(dbSrc, dbDst, false); err != nil {
    log.Warnf("db copied with WAL/SHM issues (data may be stale): %v", err)
}
Defensive patterns

Strategy: fallback

Validate before calling

// detect WAL sidecars and warn if the browser is live (copy may race)
if _, err := os.Stat(src + "-wal"); err == nil {
    log.Warnf("%s has an active WAL; close the browser for a consistent copy", src)
}

Try / catch

// Go
if err := s.Acquire(dbSrc, dbDst, false); err != nil {
    if strings.Contains(err.Error(), "copy -wal") || strings.Contains(err.Error(), "copy -shm") {
        log.Warnf("main db copied but sidecar copy failed; data may be stale: %v", err)
        return nil // continue with possibly-stale copy
    }
    return err
}

Prevention

When it happens

Trigger: Session.Acquire(src, dst, false) on any platform where src+"-wal" or src+"-shm" exists but copyFile on it fails — typically the browser holds the WAL open with exclusive access, or the WAL is being rewritten/rotated mid-copy.

Common situations: Extracting Chrome/Edge cookies while the browser is running (WAL actively written); a checkpoint deleting the WAL between isFileExists and copyFile; permission differences between the main DB and sidecar files; destination write failures.

Understand the failure class

Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.

Related errors


AI-assisted analysis of moonD4rk/HackBrowserData@0503d04d7a (2026-09-06). Data as JSON: /api/errors/61f83b4c0074ac44. Report an issue: GitHub.