> 3. Is unclear, copy may result in a corrupted backup, but the original remains uncorrupted, so you also have one uncorrupted version… Think about what happen

> 3. Is unclear, copy may result in a corrupted backup, but the original remains uncorrupted, so you also have one uncorrupted version… Think about what happens when your power comes back and you start editing that file again. Which is the correct version of the file? How can you tell? Suppose the backup file is newer than the original file, and 99% of the size. Is it a partial copy, or did the user delete some lines and then save? Now consider what Emacs does by default when `backup-by-copying` is nil and the user asks Emacs to save a file: 1. Emacs deletes the existing backup file (atomic), 2. renames the existing file so that it becomes the backup (atomic), 3. writes the buffer content into a new file with a temporary name (not atomic), 4. calls fsync(2) to ensure that all written data has actually hit the disk¹, 5. finally renames the temporary file so that it has the user’s desired filename (atomic). If the power goes off anywhere in the middle of that process, then no corruption will occur. The state on disk will be easily observable; it will either be a missing backup file but the original still exists untouched, or it will be a backup file but no original, or it will be a backup file plus a temporary file that might be incomplete, or it will be a backup file plus the new file. In all of these cases the editor can recover automatically without ever losing anything that was already saved on disk. Sure, in most of those cases we lose the _new_ data that wasn’t yet saved, but after all the power did go out in the middle of trying to save that very data. We’re not magicians here; this is the best we can do. Of course, in practice the power doesn’t go out all that often and users habitually save the document after every few words, right? So backing up by copying is safe enough that most users who prefer it never lose any data. Probably. At least as far as they know; sometimes this type of corruption goes unnoticed, or gets chalked up to other factors such as inebriation or forgetfulness. ¹ We’ll ignore the fact that some operating systems have an fsync(2) that lies. See also <https://danluu.com/file-consistency/ https://danluu.com/file-consistency/>.