Joe Gregorio
I have, for reasons that will become obvious in a week or so, been looking at
text editors and what happens when you save a file. For example, if we are editing the file
filename.txt, different things will happen when you
save the file depending on which editor you are using.
VIM is fairly straight forward in that it renames the original file
to filename.txt~, writes the modified
contents to filename.txt, and then if that is successful
deletes filename.txt~.
Emacs does roughly the same thing as VIM, but by default doesn't clean up the filename.txt~ file.
Eclipse is by far the simplest, truncating filename.txt
to a length of 0 and then writing the new contents.
Gedit is by far the most byzantine, first it writes the contents of the modified buffer
to a hidden file .gedit-save-NNNN, then it renames the original file
to filename.txt~, then renames .gedit-save-NNN to filename.txt
and finally deletes filename.txt~.
What makes Gedit really stand out from other text editors is that
if for some reason the filesystem doesn't support 'rename' then Gedit refuses
to save the file, as opposed to VIM and Emacs which will just write new
contents to filename.txt. As you can imagine that's controversial
behavior and there's
a long and painful bug thread on it, which is filled with all the painful things
you'd expect it to be filled with, like claiming it's not a bug, or that
the bug is in some other piece of software, or that it's not a problem
under 'normal' usage, or that any other way of saving files is unsafe.
Like I said, painful.
But I'm willing to believe there are even more complex cases, and if you know of an editor that has an even more convoluted save routine I'd be glad to hear about it.
Put:
set backup
...in your ~/.vimrc ... to not do the delete part (ie. dtrt. :).
I'm actually surprised that (x)emacs doesn't do the same thing as gedit, as that makes the window where you have no filename.txt much smaller. Although obviously breaking when rename doesn't work is wrong (so you can't edit symlinks in gedit?)
Posted by James Antill on 2009-01-05
jEdit lets you opt in to something like vim/emacs disk writing behavior. Its label for the option, "Two-stage save (safer but resets file owner on Unix)", does raise an interesting point about the RENAME+CREATE approach.
It seems that COPY+OVERWRITE would be safer re. preservation of file permissions and ownership. However if there was an undetected write-failure during the copy operation, the original may be truncated without a usable backup. Also, COPY+OVERWRITE would require more bytes to be written compared to RENAME+CREATE. I guess that's why emacs only falls back to the former if the latter will result in changed ownership/permissions.
Posted by Paul Annesley on 2009-01-05
Posted by James on 2009-01-05
Posted by karl on 2009-01-06
Posted by Boris Bokowski on 2009-01-06
Posted by Paul Hoffman on 2009-01-07
cp -av --link
That's just sick. I also just love the implicit implication in that FAQ that you would obviously know your text editors file saving algorithm.
Posted by Joe on 2009-01-08
There's actually more to emacs (should be no surprise).
First, emacs will keep automatic backups, like #filename.txt#, while a file is in the process of being edited (every so-many keystrokes); these go away when a file is finally successfully saved. If it can't create the auto-backup, it will warn you but will still allow you to proceed.
When saving, to create the backup file emacs can use two methods: RENAME filename.txt to filename.txt~, or COPY filename.txt to filename.txt~. It will generally try the rename approach first, if possible, unless the original file is a link or the file ownership permissions are mismatched, or the user has customized emacs to use the copying approach first.
Also emacs can perform version controlled backups, where it creates filename.txt.~1~, filename.txt.~2~, filename.txt.~3~, etc.
Another related thing that emacs does is to use lock files. This prevents (or at least alerts the user) having two different emacs processes editing the same file simultaneously and potentially overwriting the changes of the other. This feature alone has saved me countless times, as I tend to have dozens of terminals and screen sessions and ssh's going at once.
Posted by Deron Meranda on 2009-01-05