Default K file-backup modes (undel, bak) first move (rename) the original file to some backup-filename, then write an entirely new instance of the originally-named file. The permissions of the original instance of the file cannot prevent it from being renamed (only directory permissions can prevent renaming (or deletion, for that matter)).
This is troublesome when using an archaic VCS which relies on file permissions defaulting to 'no-write' to force users to checkout files from the VCS before editing them: with K, you just start editing, never having reason to notice that you should have first checked the file out from VCS.
This presents an interesting dilemma, since the described backup process is cleaner (the original file is never written, merely renamed, so the integrity of it's content is less subject to corruption); a backup process specifically designed to be impeded by lack of write permission, would (AFAICT) necessarily involve copying all of the original file bytes to a new (backup) file, then overwriting the file's content in situ.
What to do...?
And a closely related issue: new file instances created by the above-described move-then-write-new process have owner (uid/gid) == that of the K process. When editing files as root, this can easily lead to file ownership being corrupted (unintentionally changed). Solution vectors:
copy original content to newly created backup file, rewrite original file with new content.
when creating new file having original filename, attempt to force uid/gid == original file; this seems unlikely to work except when K uid == 0 (root), since non-root users cannot (I believe) write files with uid other than their own.
Default K file-backup modes (undel, bak) first move (rename) the original file to some backup-filename, then write an entirely new instance of the originally-named file. The permissions of the original instance of the file cannot prevent it from being renamed (only directory permissions can prevent renaming (or deletion, for that matter)).
This is troublesome when using an archaic VCS which relies on file permissions defaulting to 'no-write' to force users to checkout files from the VCS before editing them: with K, you just start editing, never having reason to notice that you should have first checked the file out from VCS.
This presents an interesting dilemma, since the described backup process is cleaner (the original file is never written, merely renamed, so the integrity of it's content is less subject to corruption); a backup process specifically designed to be impeded by lack of write permission, would (AFAICT) necessarily involve copying all of the original file bytes to a new (backup) file, then overwriting the file's content in situ.
What to do...?
And a closely related issue: new file instances created by the above-described move-then-write-new process have owner (uid/gid) == that of the K process. When editing files as root, this can easily lead to file ownership being corrupted (unintentionally changed). Solution vectors: