Let's say you open a file on which you have write permission. Meanwhile you change permissions and remove write permission while you still have the file open in some editor.
What will happen if you edit and save it?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
The permissions of a file are checked when the file is opened. Changing the permissions doesn't affect what processes that already have the file open can do with it. This is used sometimes with processes that start with additional privileges, open a file, then drop those additional privileges: they can still access the file but may not be able to reopen it.
However editors typically do not keep a file open. When an editor opens a document, what happens under the hood is that the editor loads the file contents in memory and closes the file. When you save the document, the editor opens the file and writes the new content.
Editors can follow one of two strategies when saving a file. They can create a new file, then move it into place. Alternatively, they can open the existing file and overwrite the old contents. Overwriting has the advantage that the file's permission and ownership do not change, and that it works even in a read-only directory. The major disadvantage of overwriting is that if saving fails midway (editor crash, system crash, disk full, …), you are left with a truncated document. Different editors choose different strategies; the good one do write-to-new-then-move if possible, and overwrite only in a read-only directory (after making a backup somewhere else).
If the editor follows the new-then-move strategy, the permissions on the file don't matter: the editor will create a new file, and it only needs write permission on the directory for that. There are two exceptions: if the directory has the sticky bit, changing the ownership of the file (but not the permission) may make it impossible for the process to move the new file into place. Another exception is on systems that support delete permission through ACLs (such as OSX): revoking the delete permission from the file may make the move impossible.
If the editor follows the overwrite strategy, revoking write permission will make saving impossible. (However, some editors that overwrite by default may fall back to new-then-move.)
In Vim, you can force the overwrite strategy by turning off the
backupcopy option; see also why inode value changes when we edit in "vi" editor?. In Emacs, you can force the overwrite strategy by setting the
backup-by-copying variable to
You can do all the edits you like, but when you try to save, your editor will complain that the file cannot be written to. If your editor creates a backup file, the changes will be obviously saved to the backup file.
Depending on your editor, you may be able to override this. In
vim for example, I can save to a non-writable file if I'm either the file's owner or
root by entering the command
! means to forcibly apply the write action). Other editors, like
gedit for instance, don't allow you to save the file and instead offer you a
Save As... option.
Thanks to msw's comment below, you should note that this behavior is actually due to the way editors are designed: they use a temporary file (buffer) to hold all your edits until you actually decide to write your buffer to the file.