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?













2















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 ?










share|improve this question























  • “Quite often” (?) indicates that you might want to fix your file permissions. This should happen very rarely.

    – Konrad Rudolph
    1 hour ago
















2















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 ?










share|improve this question























  • “Quite often” (?) indicates that you might want to fix your file permissions. This should happen very rarely.

    – Konrad Rudolph
    1 hour ago














2












2








2








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 ?










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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



















  • “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










3 Answers
3






active

oldest

votes


















5














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





share|improve this answer


























  • 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











  • 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





    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





    @JdeBP Yes I'm rapidly becoming suspicious I'm seeing something unusual or Debian specific.

    – Philip Couling
    5 hours ago



















3














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.






share|improve this answer































    2














    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





    share|improve this answer


























    • 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













    • 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













    • 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











    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    5














    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





    share|improve this answer


























    • 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











    • 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





      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





      @JdeBP Yes I'm rapidly becoming suspicious I'm seeing something unusual or Debian specific.

      – Philip Couling
      5 hours ago
















    5














    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





    share|improve this answer


























    • 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











    • 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





      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





      @JdeBP Yes I'm rapidly becoming suspicious I'm seeing something unusual or Debian specific.

      – Philip Couling
      5 hours ago














    5












    5








    5







    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





    share|improve this answer















    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






    share|improve this answer














    share|improve this answer



    share|improve this answer








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











    • 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





      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





      @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











    • @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








    • 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






    • 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













    3














    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.






    share|improve this answer




























      3














      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.






      share|improve this answer


























        3












        3








        3







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 6 hours ago









        Ingo KarkatIngo Karkat

        8,79911932




        8,79911932























            2














            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





            share|improve this answer


























            • 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













            • 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













            • 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
















            2














            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





            share|improve this answer


























            • 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













            • 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













            • 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














            2












            2








            2







            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





            share|improve this answer















            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






            share|improve this answer














            share|improve this answer



            share|improve this answer








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











            • 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



















            • 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













            • 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













            • 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

















            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


















            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Can't compile dgruyter and caption packagesLaTeX templates/packages for writing a patent specificationLatex...

            Schneeberg (Smreczany) Bibliografia | Menu...

            Hans Bellmer Spis treści Życiorys | Upamiętnienie | Przypisy | Bibliografia | Linki zewnętrzne |...