The way most editors save a file is like this:

  f = open("the_file.new")
  write(f, new_contents);
  close(f);
  rename("the_file", "the_file~");
  rename("the_file.new", "the_file");

So the old file is never modified, it's renamed to the backup copy, and an entirely new file is created to take its place.

This has a number of advantages, but does not play well with any extended info the old file used to have, unless they are copied explicitly. And in a tagging-oblivious program, they won't be.

I see a lot of saves work like this:

    f = open( "the_file.new.$$" );
    write( f, new_contents );
    close( f );
    rename( "the_file.new.$$", "the_file.new" )

If not implemented like this, then something that attempts to read "the_file.new" may get partial contents, normally truncated along the file system block size.

Backups often take place, too, like you mentioned, depending on editor.

If you do not rename files while holding their open file descriptors there's no guarantee that you are renaming the file you just wrote to.

There is no guarantee of that if one does retain the open file descriptor.

before rename:

fstat the fd, get st_dev and st_ino.

rename

stat the new name. Compare st_dev and st_ino.

If the value matches, you renamed the right file. If it does not match, you renamed a wrong file. Without holding the fd, it is impossible to know if it is the right file.

"you renamed a wrong file" shows that "there's no guarantee that you are renaming the file you just wrote to".

In this case you know that you renamed a wrong file. In the close before rename you do not know that you have renamed a wrong file.

Knowing that something bad happened after the fact is not the same as your idea that there's a guarantee that something bad will not happen.

Thanks for teaching me this! I wasn't aware. So, the original xattr (and the program that created it) would be deleted and replaced by vi for example. Still technically right, but I'm unsure how you'd keep a history.