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
- Retry the acquisition — WAL sidecars are transient; after a checkpoint the main DB may be self-contained.
- Close the browser first so the WAL is checkpointed and the sidecars become readable or disappear.
- Treat the extracted copy as potentially stale if the WAL could not be copied: verify expected rows exist before decrypting.
- 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
- Close the browser first so SQLite checkpoints and removes WAL/SHM files
- Retry if the WAL was rotated mid-copy
- Verify expected record counts in the staged DB before decryption
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.