How vim overwrites readonly mode?Vim colorize edit modeDifferent vim colorscheme depending on modeSwitching...
What's the oldest plausible frozen specimen for a Jurassic Park style story-line?
Where does documentation like business and software requirement spec docs fit in an agile project?
Reading Mishnayos without understanding
Why does 0.-5 evaluate to -5?
Caron Accent v{a} doesn't render without usepackage{xeCJK}
What species should be used for storage of human minds?
Can my friend and I spend the summer in Canada (6 weeks) at 16 years old without an adult?
Lightning Data Table inline edit
A starship is travelling at 0.9c and collides with a small rock. Will it leave a clean hole through, or will more happen?
How can I give a Ranger advantage on a check due to Favored Enemy without spoiling the story for the player?
Allow console draw poker game to output more hands
What does an unprocessed RAW file look like?
Why is it that Bernie Sanders is always called a "socialist"?
I have trouble understanding this fallacy: "If A, then B. Therefore if not-B, then not-A."
Count repetitions of an array
Concatenating two int[]
Single-row INSERT...SELECT much slower than separate SELECT
Am I correct in stating that the study of topology is purely theoretical?
Boss asked me to sign a resignation paper without a date on it along with my new contract
What can I do to encourage my players to use their consumables?
Converting very wide logos to square formats
Was there a pre-determined arrangement for the division of Germany in case it surrendered before any Soviet forces entered its territory?
Website seeing my Facebook data?
Potential client has a problematic employee I can't work with
How vim overwrites readonly mode?
Vim colorize edit modeDifferent vim colorscheme depending on modeSwitching to edit mode in VIM rc?Can you further integrate and present sequential moreutils vipe command output in vim using successive splits etc?Glitch with auto chmod line in .vimrcCan vim edit a remote file as root?`vim` brings me to lockout [Unity bug? Solved…ish]Any way to recall the file of previous cmd?Why is vim frozen?Why updates overwrites Vim that built from source?
Quite often we see that the file we are trying to save in vim after edit is reported to be read-only. The way around this is to add !wq
, i am trying to figure out what internally goes that allows the vim program to gain enough permission to write the read-only file ?
Is there a internal flag which is switched or the vim temporarily gains the privileges for some time ?
shell vim
add a comment |
Quite often we see that the file we are trying to save in vim after edit is reported to be read-only. The way around this is to add !wq
, i am trying to figure out what internally goes that allows the vim program to gain enough permission to write the read-only file ?
Is there a internal flag which is switched or the vim temporarily gains the privileges for some time ?
shell vim
“Quite often” (?) indicates that you might want to fix your file permissions. This should happen very rarely.
– Konrad Rudolph
1 hour ago
add a comment |
Quite often we see that the file we are trying to save in vim after edit is reported to be read-only. The way around this is to add !wq
, i am trying to figure out what internally goes that allows the vim program to gain enough permission to write the read-only file ?
Is there a internal flag which is switched or the vim temporarily gains the privileges for some time ?
shell vim
Quite often we see that the file we are trying to save in vim after edit is reported to be read-only. The way around this is to add !wq
, i am trying to figure out what internally goes that allows the vim program to gain enough permission to write the read-only file ?
Is there a internal flag which is switched or the vim temporarily gains the privileges for some time ?
shell vim
shell vim
asked 6 hours ago
AtulAtul
3712519
3712519
“Quite often” (?) indicates that you might want to fix your file permissions. This should happen very rarely.
– Konrad Rudolph
1 hour ago
add a comment |
“Quite often” (?) indicates that you might want to fix your file permissions. This should happen very rarely.
– Konrad Rudolph
1 hour ago
“Quite often” (?) indicates that you might want to fix your file permissions. This should happen very rarely.
– Konrad Rudolph
1 hour ago
“Quite often” (?) indicates that you might want to fix your file permissions. This should happen very rarely.
– Konrad Rudolph
1 hour ago
add a comment |
3 Answers
3
active
oldest
votes
When you do w!
in Vim, what actually happens depends on who owns the file.
If you (the current user) are the owner of the file, Vim will change the permissions to be writable before rewriting the file. It then removes the write permissions to restore the permission bits to what it was from the start.
If you are not the owner of the file, but if you have write permissions in the current directory, Vim will delete the original file and write the document to a new file with the same name. The new file will then be assigned the same permissions as the original file, but will be owned by you.
This is the first case (output from ktrace
+kdump
on OpenBSD):
13228 vim CALL chmod(0x19b1d94b4b10,0100644<S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH|S_IFREG>)
13228 vim NAMI "file"
13228 vim RET chmod 0
13228 vim CALL lseek(3,0x1000,SEEK_SET)
13228 vim RET lseek 4096/0x1000
13228 vim CALL write(3,0x19b1e0aa9000,0x1000)
This changes permissions on the file so that it's writable (the S_IWUSR
flag used with chmod()
) and writes the buffer to it.
It then sets the original permissions:
13228 vim CALL fchmod(4,0100444<S_IRUSR|S_IRGRP|S_IROTH|S_IFREG>)
13228 vim RET fchmod 0
13228 vim CALL close(4)
13228 vim RET close 0
For the other case:
It first unlinks (deletes) the file and then recreates it (before writing to the file and changing permissions later):
44487 vim CALL unlink(0x79fdbc1f000)
44487 vim NAMI "file"
44487 vim RET unlink 0
44487 vim CALL open(0x79fdbc1f000,0x201<O_WRONLY|O_CREAT>,0644<S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH>)
44487 vim NAMI "file"
44487 vim RET open 4
It's really odd that you would get different results (even on a different OS) for the same software. Could you confirm the version you are using and the value of the two relavent config options you mention (backup
andbackupcopy
)
– Philip Couling
5 hours ago
@PhilipCouling Vim 8.1.800. Bothbackup
andbackupcopy
are unset (this is without a private.vimrc
file).
– Kusalananda
5 hours ago
Likewise neither of mine are set in config and8.1.800
is very close to8.1.875
, could you also confirm the result ofset backup?
andset backupcopy?
It's plausible the good people at Debian compiled in something different.
– Philip Couling
5 hours ago
1
I did atruss
on FreeBSD of both VIM and NeoVIM. I even checked nvi for good measure. I duplicated Kusalananda's results with all three.
– JdeBP
5 hours ago
1
@JdeBP Yes I'm rapidly becoming suspicious I'm seeing something unusual or Debian specific.
– Philip Couling
5 hours ago
add a comment |
Vim cannot gain additional permissions. The :w!
just overrides the internal 'readonly'
option, which may have been set because:
- you've opened the file via the
-R
command-line option or with:view
instead of:edit
, or:setlocal readonly
- Vim recognizes that the file currently doesn't have write permissions
For the latter case, a file write may still be possible because Vim (by default) creates a new file and then replaces the original file with it. That still depends on the permissions being set in a way to allow this.
To really gain write permissions where the user that opened Vim doesn't have any, the :w !sudo tee >/dev/null file
trick has to be used, either directly, or through a plugin like SudoEdit.
add a comment |
You can't ever write to a file that you don't have write permissions on. However you can delete that file if you have write permissions on the directory.
The trick that VIM is using is to delete the file and write a new one.
It's possible to show this is the method VIM uses without reading source code by checking the inode number before and after:
$ touch foo
$ chmod u-w foo
$ ls -li foo
60818465 -r--r----- 1 philip philip 0 Feb 25 10:24 foo
$ vi foo
$ # edit the file and save with :w!
$ ls -li foo
60818467 -r--r----- 1 philip philip 8 Feb 25 10:25 foo
Note that the inode number changed showing that the new file is NOT the same file as the one you edited.
FYI My current config is really short:
runtime! debian.vim
if has("syntax")
syntax on
endif
set tabstop=4
set autoindent
And debian packages installed are:
vim 2:8.1.0875-1
vim-common 2:8.1.0875-1
vim-runtime 2:8.1.0875-1
vim-tiny 2:8.1.0875-1
Changing permissions on the file is exactly what Vim does, at least on OpenBSD.
– Kusalananda
6 hours ago
@Kusalananda as per the experement above, not in Debian withVim 2:8.1.0875-1
. The file is clearly being completely replaced.
– Philip Couling
5 hours ago
This is not the method that VIM uses by default. The doco (:help :write
) states that it temporarily changes permissions, and a quicktruss
confirms that the doco is right. You have non-default backup options set.
– JdeBP
5 hours ago
The phrase "by default" means "what happens if not otherwise configired" no? And:set backupcopy?
results inbackupcopy=auto
. I've checked my config. There's nothing in there to change this behaviour (I think?)
– Philip Couling
5 hours ago
whenvim
is in compatible mode,:w!
will only override the read-only mode of the buffer, but will not try to change the file perms back and forth or do other amateur hour stuff. This is the only right behavior -- it would be nice if it was clearly mentioned which one of the options turned on or off by:set compatible
is responsible for this.
– mosvy
5 hours ago
|
show 4 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502826%2fhow-vim-overwrites-readonly-mode%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
When you do w!
in Vim, what actually happens depends on who owns the file.
If you (the current user) are the owner of the file, Vim will change the permissions to be writable before rewriting the file. It then removes the write permissions to restore the permission bits to what it was from the start.
If you are not the owner of the file, but if you have write permissions in the current directory, Vim will delete the original file and write the document to a new file with the same name. The new file will then be assigned the same permissions as the original file, but will be owned by you.
This is the first case (output from ktrace
+kdump
on OpenBSD):
13228 vim CALL chmod(0x19b1d94b4b10,0100644<S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH|S_IFREG>)
13228 vim NAMI "file"
13228 vim RET chmod 0
13228 vim CALL lseek(3,0x1000,SEEK_SET)
13228 vim RET lseek 4096/0x1000
13228 vim CALL write(3,0x19b1e0aa9000,0x1000)
This changes permissions on the file so that it's writable (the S_IWUSR
flag used with chmod()
) and writes the buffer to it.
It then sets the original permissions:
13228 vim CALL fchmod(4,0100444<S_IRUSR|S_IRGRP|S_IROTH|S_IFREG>)
13228 vim RET fchmod 0
13228 vim CALL close(4)
13228 vim RET close 0
For the other case:
It first unlinks (deletes) the file and then recreates it (before writing to the file and changing permissions later):
44487 vim CALL unlink(0x79fdbc1f000)
44487 vim NAMI "file"
44487 vim RET unlink 0
44487 vim CALL open(0x79fdbc1f000,0x201<O_WRONLY|O_CREAT>,0644<S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH>)
44487 vim NAMI "file"
44487 vim RET open 4
It's really odd that you would get different results (even on a different OS) for the same software. Could you confirm the version you are using and the value of the two relavent config options you mention (backup
andbackupcopy
)
– Philip Couling
5 hours ago
@PhilipCouling Vim 8.1.800. Bothbackup
andbackupcopy
are unset (this is without a private.vimrc
file).
– Kusalananda
5 hours ago
Likewise neither of mine are set in config and8.1.800
is very close to8.1.875
, could you also confirm the result ofset backup?
andset backupcopy?
It's plausible the good people at Debian compiled in something different.
– Philip Couling
5 hours ago
1
I did atruss
on FreeBSD of both VIM and NeoVIM. I even checked nvi for good measure. I duplicated Kusalananda's results with all three.
– JdeBP
5 hours ago
1
@JdeBP Yes I'm rapidly becoming suspicious I'm seeing something unusual or Debian specific.
– Philip Couling
5 hours ago
add a comment |
When you do w!
in Vim, what actually happens depends on who owns the file.
If you (the current user) are the owner of the file, Vim will change the permissions to be writable before rewriting the file. It then removes the write permissions to restore the permission bits to what it was from the start.
If you are not the owner of the file, but if you have write permissions in the current directory, Vim will delete the original file and write the document to a new file with the same name. The new file will then be assigned the same permissions as the original file, but will be owned by you.
This is the first case (output from ktrace
+kdump
on OpenBSD):
13228 vim CALL chmod(0x19b1d94b4b10,0100644<S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH|S_IFREG>)
13228 vim NAMI "file"
13228 vim RET chmod 0
13228 vim CALL lseek(3,0x1000,SEEK_SET)
13228 vim RET lseek 4096/0x1000
13228 vim CALL write(3,0x19b1e0aa9000,0x1000)
This changes permissions on the file so that it's writable (the S_IWUSR
flag used with chmod()
) and writes the buffer to it.
It then sets the original permissions:
13228 vim CALL fchmod(4,0100444<S_IRUSR|S_IRGRP|S_IROTH|S_IFREG>)
13228 vim RET fchmod 0
13228 vim CALL close(4)
13228 vim RET close 0
For the other case:
It first unlinks (deletes) the file and then recreates it (before writing to the file and changing permissions later):
44487 vim CALL unlink(0x79fdbc1f000)
44487 vim NAMI "file"
44487 vim RET unlink 0
44487 vim CALL open(0x79fdbc1f000,0x201<O_WRONLY|O_CREAT>,0644<S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH>)
44487 vim NAMI "file"
44487 vim RET open 4
It's really odd that you would get different results (even on a different OS) for the same software. Could you confirm the version you are using and the value of the two relavent config options you mention (backup
andbackupcopy
)
– Philip Couling
5 hours ago
@PhilipCouling Vim 8.1.800. Bothbackup
andbackupcopy
are unset (this is without a private.vimrc
file).
– Kusalananda
5 hours ago
Likewise neither of mine are set in config and8.1.800
is very close to8.1.875
, could you also confirm the result ofset backup?
andset backupcopy?
It's plausible the good people at Debian compiled in something different.
– Philip Couling
5 hours ago
1
I did atruss
on FreeBSD of both VIM and NeoVIM. I even checked nvi for good measure. I duplicated Kusalananda's results with all three.
– JdeBP
5 hours ago
1
@JdeBP Yes I'm rapidly becoming suspicious I'm seeing something unusual or Debian specific.
– Philip Couling
5 hours ago
add a comment |
When you do w!
in Vim, what actually happens depends on who owns the file.
If you (the current user) are the owner of the file, Vim will change the permissions to be writable before rewriting the file. It then removes the write permissions to restore the permission bits to what it was from the start.
If you are not the owner of the file, but if you have write permissions in the current directory, Vim will delete the original file and write the document to a new file with the same name. The new file will then be assigned the same permissions as the original file, but will be owned by you.
This is the first case (output from ktrace
+kdump
on OpenBSD):
13228 vim CALL chmod(0x19b1d94b4b10,0100644<S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH|S_IFREG>)
13228 vim NAMI "file"
13228 vim RET chmod 0
13228 vim CALL lseek(3,0x1000,SEEK_SET)
13228 vim RET lseek 4096/0x1000
13228 vim CALL write(3,0x19b1e0aa9000,0x1000)
This changes permissions on the file so that it's writable (the S_IWUSR
flag used with chmod()
) and writes the buffer to it.
It then sets the original permissions:
13228 vim CALL fchmod(4,0100444<S_IRUSR|S_IRGRP|S_IROTH|S_IFREG>)
13228 vim RET fchmod 0
13228 vim CALL close(4)
13228 vim RET close 0
For the other case:
It first unlinks (deletes) the file and then recreates it (before writing to the file and changing permissions later):
44487 vim CALL unlink(0x79fdbc1f000)
44487 vim NAMI "file"
44487 vim RET unlink 0
44487 vim CALL open(0x79fdbc1f000,0x201<O_WRONLY|O_CREAT>,0644<S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH>)
44487 vim NAMI "file"
44487 vim RET open 4
When you do w!
in Vim, what actually happens depends on who owns the file.
If you (the current user) are the owner of the file, Vim will change the permissions to be writable before rewriting the file. It then removes the write permissions to restore the permission bits to what it was from the start.
If you are not the owner of the file, but if you have write permissions in the current directory, Vim will delete the original file and write the document to a new file with the same name. The new file will then be assigned the same permissions as the original file, but will be owned by you.
This is the first case (output from ktrace
+kdump
on OpenBSD):
13228 vim CALL chmod(0x19b1d94b4b10,0100644<S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH|S_IFREG>)
13228 vim NAMI "file"
13228 vim RET chmod 0
13228 vim CALL lseek(3,0x1000,SEEK_SET)
13228 vim RET lseek 4096/0x1000
13228 vim CALL write(3,0x19b1e0aa9000,0x1000)
This changes permissions on the file so that it's writable (the S_IWUSR
flag used with chmod()
) and writes the buffer to it.
It then sets the original permissions:
13228 vim CALL fchmod(4,0100444<S_IRUSR|S_IRGRP|S_IROTH|S_IFREG>)
13228 vim RET fchmod 0
13228 vim CALL close(4)
13228 vim RET close 0
For the other case:
It first unlinks (deletes) the file and then recreates it (before writing to the file and changing permissions later):
44487 vim CALL unlink(0x79fdbc1f000)
44487 vim NAMI "file"
44487 vim RET unlink 0
44487 vim CALL open(0x79fdbc1f000,0x201<O_WRONLY|O_CREAT>,0644<S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH>)
44487 vim NAMI "file"
44487 vim RET open 4
edited 4 hours ago
answered 6 hours ago
KusalanandaKusalananda
132k17252415
132k17252415
It's really odd that you would get different results (even on a different OS) for the same software. Could you confirm the version you are using and the value of the two relavent config options you mention (backup
andbackupcopy
)
– Philip Couling
5 hours ago
@PhilipCouling Vim 8.1.800. Bothbackup
andbackupcopy
are unset (this is without a private.vimrc
file).
– Kusalananda
5 hours ago
Likewise neither of mine are set in config and8.1.800
is very close to8.1.875
, could you also confirm the result ofset backup?
andset backupcopy?
It's plausible the good people at Debian compiled in something different.
– Philip Couling
5 hours ago
1
I did atruss
on FreeBSD of both VIM and NeoVIM. I even checked nvi for good measure. I duplicated Kusalananda's results with all three.
– JdeBP
5 hours ago
1
@JdeBP Yes I'm rapidly becoming suspicious I'm seeing something unusual or Debian specific.
– Philip Couling
5 hours ago
add a comment |
It's really odd that you would get different results (even on a different OS) for the same software. Could you confirm the version you are using and the value of the two relavent config options you mention (backup
andbackupcopy
)
– Philip Couling
5 hours ago
@PhilipCouling Vim 8.1.800. Bothbackup
andbackupcopy
are unset (this is without a private.vimrc
file).
– Kusalananda
5 hours ago
Likewise neither of mine are set in config and8.1.800
is very close to8.1.875
, could you also confirm the result ofset backup?
andset backupcopy?
It's plausible the good people at Debian compiled in something different.
– Philip Couling
5 hours ago
1
I did atruss
on FreeBSD of both VIM and NeoVIM. I even checked nvi for good measure. I duplicated Kusalananda's results with all three.
– JdeBP
5 hours ago
1
@JdeBP Yes I'm rapidly becoming suspicious I'm seeing something unusual or Debian specific.
– Philip Couling
5 hours ago
It's really odd that you would get different results (even on a different OS) for the same software. Could you confirm the version you are using and the value of the two relavent config options you mention (
backup
and backupcopy
)– Philip Couling
5 hours ago
It's really odd that you would get different results (even on a different OS) for the same software. Could you confirm the version you are using and the value of the two relavent config options you mention (
backup
and backupcopy
)– Philip Couling
5 hours ago
@PhilipCouling Vim 8.1.800. Both
backup
and backupcopy
are unset (this is without a private .vimrc
file).– Kusalananda
5 hours ago
@PhilipCouling Vim 8.1.800. Both
backup
and backupcopy
are unset (this is without a private .vimrc
file).– Kusalananda
5 hours ago
Likewise neither of mine are set in config and
8.1.800
is very close to 8.1.875
, could you also confirm the result of set backup?
and set backupcopy?
It's plausible the good people at Debian compiled in something different.– Philip Couling
5 hours ago
Likewise neither of mine are set in config and
8.1.800
is very close to 8.1.875
, could you also confirm the result of set backup?
and set backupcopy?
It's plausible the good people at Debian compiled in something different.– Philip Couling
5 hours ago
1
1
I did a
truss
on FreeBSD of both VIM and NeoVIM. I even checked nvi for good measure. I duplicated Kusalananda's results with all three.– JdeBP
5 hours ago
I did a
truss
on FreeBSD of both VIM and NeoVIM. I even checked nvi for good measure. I duplicated Kusalananda's results with all three.– JdeBP
5 hours ago
1
1
@JdeBP Yes I'm rapidly becoming suspicious I'm seeing something unusual or Debian specific.
– Philip Couling
5 hours ago
@JdeBP Yes I'm rapidly becoming suspicious I'm seeing something unusual or Debian specific.
– Philip Couling
5 hours ago
add a comment |
Vim cannot gain additional permissions. The :w!
just overrides the internal 'readonly'
option, which may have been set because:
- you've opened the file via the
-R
command-line option or with:view
instead of:edit
, or:setlocal readonly
- Vim recognizes that the file currently doesn't have write permissions
For the latter case, a file write may still be possible because Vim (by default) creates a new file and then replaces the original file with it. That still depends on the permissions being set in a way to allow this.
To really gain write permissions where the user that opened Vim doesn't have any, the :w !sudo tee >/dev/null file
trick has to be used, either directly, or through a plugin like SudoEdit.
add a comment |
Vim cannot gain additional permissions. The :w!
just overrides the internal 'readonly'
option, which may have been set because:
- you've opened the file via the
-R
command-line option or with:view
instead of:edit
, or:setlocal readonly
- Vim recognizes that the file currently doesn't have write permissions
For the latter case, a file write may still be possible because Vim (by default) creates a new file and then replaces the original file with it. That still depends on the permissions being set in a way to allow this.
To really gain write permissions where the user that opened Vim doesn't have any, the :w !sudo tee >/dev/null file
trick has to be used, either directly, or through a plugin like SudoEdit.
add a comment |
Vim cannot gain additional permissions. The :w!
just overrides the internal 'readonly'
option, which may have been set because:
- you've opened the file via the
-R
command-line option or with:view
instead of:edit
, or:setlocal readonly
- Vim recognizes that the file currently doesn't have write permissions
For the latter case, a file write may still be possible because Vim (by default) creates a new file and then replaces the original file with it. That still depends on the permissions being set in a way to allow this.
To really gain write permissions where the user that opened Vim doesn't have any, the :w !sudo tee >/dev/null file
trick has to be used, either directly, or through a plugin like SudoEdit.
Vim cannot gain additional permissions. The :w!
just overrides the internal 'readonly'
option, which may have been set because:
- you've opened the file via the
-R
command-line option or with:view
instead of:edit
, or:setlocal readonly
- Vim recognizes that the file currently doesn't have write permissions
For the latter case, a file write may still be possible because Vim (by default) creates a new file and then replaces the original file with it. That still depends on the permissions being set in a way to allow this.
To really gain write permissions where the user that opened Vim doesn't have any, the :w !sudo tee >/dev/null file
trick has to be used, either directly, or through a plugin like SudoEdit.
answered 6 hours ago
Ingo KarkatIngo Karkat
8,79911932
8,79911932
add a comment |
add a comment |
You can't ever write to a file that you don't have write permissions on. However you can delete that file if you have write permissions on the directory.
The trick that VIM is using is to delete the file and write a new one.
It's possible to show this is the method VIM uses without reading source code by checking the inode number before and after:
$ touch foo
$ chmod u-w foo
$ ls -li foo
60818465 -r--r----- 1 philip philip 0 Feb 25 10:24 foo
$ vi foo
$ # edit the file and save with :w!
$ ls -li foo
60818467 -r--r----- 1 philip philip 8 Feb 25 10:25 foo
Note that the inode number changed showing that the new file is NOT the same file as the one you edited.
FYI My current config is really short:
runtime! debian.vim
if has("syntax")
syntax on
endif
set tabstop=4
set autoindent
And debian packages installed are:
vim 2:8.1.0875-1
vim-common 2:8.1.0875-1
vim-runtime 2:8.1.0875-1
vim-tiny 2:8.1.0875-1
Changing permissions on the file is exactly what Vim does, at least on OpenBSD.
– Kusalananda
6 hours ago
@Kusalananda as per the experement above, not in Debian withVim 2:8.1.0875-1
. The file is clearly being completely replaced.
– Philip Couling
5 hours ago
This is not the method that VIM uses by default. The doco (:help :write
) states that it temporarily changes permissions, and a quicktruss
confirms that the doco is right. You have non-default backup options set.
– JdeBP
5 hours ago
The phrase "by default" means "what happens if not otherwise configired" no? And:set backupcopy?
results inbackupcopy=auto
. I've checked my config. There's nothing in there to change this behaviour (I think?)
– Philip Couling
5 hours ago
whenvim
is in compatible mode,:w!
will only override the read-only mode of the buffer, but will not try to change the file perms back and forth or do other amateur hour stuff. This is the only right behavior -- it would be nice if it was clearly mentioned which one of the options turned on or off by:set compatible
is responsible for this.
– mosvy
5 hours ago
|
show 4 more comments
You can't ever write to a file that you don't have write permissions on. However you can delete that file if you have write permissions on the directory.
The trick that VIM is using is to delete the file and write a new one.
It's possible to show this is the method VIM uses without reading source code by checking the inode number before and after:
$ touch foo
$ chmod u-w foo
$ ls -li foo
60818465 -r--r----- 1 philip philip 0 Feb 25 10:24 foo
$ vi foo
$ # edit the file and save with :w!
$ ls -li foo
60818467 -r--r----- 1 philip philip 8 Feb 25 10:25 foo
Note that the inode number changed showing that the new file is NOT the same file as the one you edited.
FYI My current config is really short:
runtime! debian.vim
if has("syntax")
syntax on
endif
set tabstop=4
set autoindent
And debian packages installed are:
vim 2:8.1.0875-1
vim-common 2:8.1.0875-1
vim-runtime 2:8.1.0875-1
vim-tiny 2:8.1.0875-1
Changing permissions on the file is exactly what Vim does, at least on OpenBSD.
– Kusalananda
6 hours ago
@Kusalananda as per the experement above, not in Debian withVim 2:8.1.0875-1
. The file is clearly being completely replaced.
– Philip Couling
5 hours ago
This is not the method that VIM uses by default. The doco (:help :write
) states that it temporarily changes permissions, and a quicktruss
confirms that the doco is right. You have non-default backup options set.
– JdeBP
5 hours ago
The phrase "by default" means "what happens if not otherwise configired" no? And:set backupcopy?
results inbackupcopy=auto
. I've checked my config. There's nothing in there to change this behaviour (I think?)
– Philip Couling
5 hours ago
whenvim
is in compatible mode,:w!
will only override the read-only mode of the buffer, but will not try to change the file perms back and forth or do other amateur hour stuff. This is the only right behavior -- it would be nice if it was clearly mentioned which one of the options turned on or off by:set compatible
is responsible for this.
– mosvy
5 hours ago
|
show 4 more comments
You can't ever write to a file that you don't have write permissions on. However you can delete that file if you have write permissions on the directory.
The trick that VIM is using is to delete the file and write a new one.
It's possible to show this is the method VIM uses without reading source code by checking the inode number before and after:
$ touch foo
$ chmod u-w foo
$ ls -li foo
60818465 -r--r----- 1 philip philip 0 Feb 25 10:24 foo
$ vi foo
$ # edit the file and save with :w!
$ ls -li foo
60818467 -r--r----- 1 philip philip 8 Feb 25 10:25 foo
Note that the inode number changed showing that the new file is NOT the same file as the one you edited.
FYI My current config is really short:
runtime! debian.vim
if has("syntax")
syntax on
endif
set tabstop=4
set autoindent
And debian packages installed are:
vim 2:8.1.0875-1
vim-common 2:8.1.0875-1
vim-runtime 2:8.1.0875-1
vim-tiny 2:8.1.0875-1
You can't ever write to a file that you don't have write permissions on. However you can delete that file if you have write permissions on the directory.
The trick that VIM is using is to delete the file and write a new one.
It's possible to show this is the method VIM uses without reading source code by checking the inode number before and after:
$ touch foo
$ chmod u-w foo
$ ls -li foo
60818465 -r--r----- 1 philip philip 0 Feb 25 10:24 foo
$ vi foo
$ # edit the file and save with :w!
$ ls -li foo
60818467 -r--r----- 1 philip philip 8 Feb 25 10:25 foo
Note that the inode number changed showing that the new file is NOT the same file as the one you edited.
FYI My current config is really short:
runtime! debian.vim
if has("syntax")
syntax on
endif
set tabstop=4
set autoindent
And debian packages installed are:
vim 2:8.1.0875-1
vim-common 2:8.1.0875-1
vim-runtime 2:8.1.0875-1
vim-tiny 2:8.1.0875-1
edited 5 hours ago
answered 6 hours ago
Philip CoulingPhilip Couling
1,211917
1,211917
Changing permissions on the file is exactly what Vim does, at least on OpenBSD.
– Kusalananda
6 hours ago
@Kusalananda as per the experement above, not in Debian withVim 2:8.1.0875-1
. The file is clearly being completely replaced.
– Philip Couling
5 hours ago
This is not the method that VIM uses by default. The doco (:help :write
) states that it temporarily changes permissions, and a quicktruss
confirms that the doco is right. You have non-default backup options set.
– JdeBP
5 hours ago
The phrase "by default" means "what happens if not otherwise configired" no? And:set backupcopy?
results inbackupcopy=auto
. I've checked my config. There's nothing in there to change this behaviour (I think?)
– Philip Couling
5 hours ago
whenvim
is in compatible mode,:w!
will only override the read-only mode of the buffer, but will not try to change the file perms back and forth or do other amateur hour stuff. This is the only right behavior -- it would be nice if it was clearly mentioned which one of the options turned on or off by:set compatible
is responsible for this.
– mosvy
5 hours ago
|
show 4 more comments
Changing permissions on the file is exactly what Vim does, at least on OpenBSD.
– Kusalananda
6 hours ago
@Kusalananda as per the experement above, not in Debian withVim 2:8.1.0875-1
. The file is clearly being completely replaced.
– Philip Couling
5 hours ago
This is not the method that VIM uses by default. The doco (:help :write
) states that it temporarily changes permissions, and a quicktruss
confirms that the doco is right. You have non-default backup options set.
– JdeBP
5 hours ago
The phrase "by default" means "what happens if not otherwise configired" no? And:set backupcopy?
results inbackupcopy=auto
. I've checked my config. There's nothing in there to change this behaviour (I think?)
– Philip Couling
5 hours ago
whenvim
is in compatible mode,:w!
will only override the read-only mode of the buffer, but will not try to change the file perms back and forth or do other amateur hour stuff. This is the only right behavior -- it would be nice if it was clearly mentioned which one of the options turned on or off by:set compatible
is responsible for this.
– mosvy
5 hours ago
Changing permissions on the file is exactly what Vim does, at least on OpenBSD.
– Kusalananda
6 hours ago
Changing permissions on the file is exactly what Vim does, at least on OpenBSD.
– Kusalananda
6 hours ago
@Kusalananda as per the experement above, not in Debian with
Vim 2:8.1.0875-1
. The file is clearly being completely replaced.– Philip Couling
5 hours ago
@Kusalananda as per the experement above, not in Debian with
Vim 2:8.1.0875-1
. The file is clearly being completely replaced.– Philip Couling
5 hours ago
This is not the method that VIM uses by default. The doco (
:help :write
) states that it temporarily changes permissions, and a quick truss
confirms that the doco is right. You have non-default backup options set.– JdeBP
5 hours ago
This is not the method that VIM uses by default. The doco (
:help :write
) states that it temporarily changes permissions, and a quick truss
confirms that the doco is right. You have non-default backup options set.– JdeBP
5 hours ago
The phrase "by default" means "what happens if not otherwise configired" no? And
:set backupcopy?
results in backupcopy=auto
. I've checked my config. There's nothing in there to change this behaviour (I think?)– Philip Couling
5 hours ago
The phrase "by default" means "what happens if not otherwise configired" no? And
:set backupcopy?
results in backupcopy=auto
. I've checked my config. There's nothing in there to change this behaviour (I think?)– Philip Couling
5 hours ago
when
vim
is in compatible mode, :w!
will only override the read-only mode of the buffer, but will not try to change the file perms back and forth or do other amateur hour stuff. This is the only right behavior -- it would be nice if it was clearly mentioned which one of the options turned on or off by :set compatible
is responsible for this.– mosvy
5 hours ago
when
vim
is in compatible mode, :w!
will only override the read-only mode of the buffer, but will not try to change the file perms back and forth or do other amateur hour stuff. This is the only right behavior -- it would be nice if it was clearly mentioned which one of the options turned on or off by :set compatible
is responsible for this.– mosvy
5 hours ago
|
show 4 more comments
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f502826%2fhow-vim-overwrites-readonly-mode%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
“Quite often” (?) indicates that you might want to fix your file permissions. This should happen very rarely.
– Konrad Rudolph
1 hour ago