Configuring love.filesystem backup restoration without atomic write guarantees

Goal: ensure that after restoring a backup file the restored content exactly matches the original backup, despite love.filesystem’s non‑atomic writes and lack of built‑in verification.

Constraints: love.filesystem.write does not guarantee atomic writes across platforms, there is no built‑in function to compare the restored file with the backup, and simultaneous read/write on the same file within a frame can lead to inconsistent results on some operating systems. These factors leave developers uncertain about how to reliably verify restoration success without implementing their own checksum or locking mechanism.

Questions: What is the recommended method to verify backup integrity after restoration? How can developers safely handle simultaneous read/write on the same file to avoid corruption? Should a fallback verification step using external hashing be integrated into the workflow, and if so, where should it occur?