Four silent data-loss bugs in file-sync tools and how to fix them

A developer building a Git-style file-sync tool identified four critical bugs that can silently destroy user data without crashing or failing tests. The first issue involves os.WriteFile truncating files before writing, which can leave corrupted fragments if interrupted — fixed by writing to a temp file and using an atomic rename. A flawed conflict-detection approach that compares only metadata like etags can overwrite local edits when both sides change, so hash-based comparison against a last-synced state is required instead. Prune or mirror operations risk deleting files the tool never created, meaning deletions should only target files the tool can prove it wrote and the user has not since modified. Across all four cases, maintaining an accurate local ledger of synced files is essential to avoid misattributing tool-caused corruption as user error.