3 replaced http://unix.stackexchange.com/ with https://unix.stackexchange.com/
source | link

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 http://unix.stackexchange.com/questions/36467/why-inode-value-changes-when-we-edit-in-vi-editorwhy 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 t.

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 http://unix.stackexchange.com/questions/36467/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 t.

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 t.

2 added 459 characters in body
source | link

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 http://unix.stackexchange.com/questions/36467/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 t.

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.)

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 http://unix.stackexchange.com/questions/36467/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 t.

1
source | link

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.)