log.Fatal from worker goroutines leaves the tree in a partially-modified state

[dolph]

Summary

Every error path in find_replace.go and file_handling.go calls log.Fatalf, which calls os.Exit(1). os.Exit does not run deferreds, so:

• In-flight goroutines (one per directory entry) are abruptly terminated mid-Rename/Write.
• Temp files in nearby directories are left behind (see Tempfile is leaked on the filesystem when atomic rename fails #5).
• The directory tree ends up half-renamed with no indication of where the failure occurred.

A single permission-denied os.ReadDir (e.g., a .cache subdir owned by another user) takes down the entire run, even though the rest of the tree could still be processed.

Impact (Reliability: High)

• Half-finished operations are unrecoverable — the user can't tell which subtree was processed and which wasn't.
• Even read-only failures (e.g., a single stat on a broken symlink) are fatal.
• Concurrent goroutines may be at any point in their pipeline when one dies, so files can be left as bare temp files or with mixed names.

Suggested Fix

• Stop calling log.Fatal from anywhere except main.
• Bubble errors up via return values (or an errgroup).
• Default policy: log the error, skip the failing entry, continue with the rest.
• Optional --strict flag to abort on first error (after a clean shutdown).
• main should exit non-zero if any error was encountered.

Files

• All log.Fatal* sites in find_replace.go and file_handling.go