UPDATE: I've tried both the :set noswapfile swapfile solution and the :e! solution and the swapfile one is better because it retains undo history even for large files, in this case meaning over 1.5 MB. For some reason, :e! does not keep undo history in those cases even though it does keep it in the normal case (say sub-100KB). The swapfile solution appears to me now to work under any circumstances, which is very impressive.

A bit of a weird question: How can I cleanly get rid of or move past the error message "E297: Write error in swap file"? I am running GVim when this happens and do not want to be forced to close it down and reopen a new GVim because I don't want to lose all my open buffers and ideally I'd like to keep all my undo history in each file too, but even a solution where I lose undo history would be an improvement. I have one limited workaround right now noted at bottom and am looking for something a little better...

Why would I want to ignore such an error? A good question: I am running GVim in a virtual machine and I have it open on a file on the "host" file system rather than the VM's own file system and I "suspend" the VM. After coming back from the suspend, every GVim window open on a host system file will give this message. So the message is evidently due to the disconnection from the host file system that has to occur when the VM is suspended. GVim obviously thinks it still has a valid perhaps file descriptor and such when it doesn't.

So the way the error arises is not anything alarming and I just need or want a way to move past it without having to close GVim and reopen it. For example, many times I might have this GVim open with many buffers and a lot of things going on. I don't want to be forced to shut down the whole GVim session because of this one error, or even to shut down all buffers open on the host system's file system. When the error occurs, it's quite annoying and pops up every few moments.

What I tried so far is doing :e on the same file, hoping that might be like refreshing from the file system, and that did not get rid of the error.

I have also tried sort of the nuclear option, :bw to get rid of the buffer where this is occurring and that does work, but as I say ideally I would like to keep the session in the same state as much as possible, so shutting down buffers is not ideal either. Like let's say I have GVim open on 10 files on the host system. If I have to shut down all the buffers, then it's just as bad as having to shut down GVim altogether.

All of this applies to the command line Vim as well, and I'm using version 7.4 on Linux.

5 Answers 5


I would try to globally disable swapfiles and then reenable them for all buffers. Something like this:

:bufdo :set noswapfile swapfile

(One might want to check, whether the current buffer has a swapfile enabled before resetting this option).

  • This seems to work! Trying it right now (just buffer by buffer rather than with :bufdo). Also, this gives the ideal behavior I was referring to where I do not even lose undo history! Question though, if I want to do this buffer by buffer as I'm describing I'm doing is it technically best to do :set noswapfile swapfile in order to not affect other buffers or should I be restricting it some way. Commented Feb 24, 2016 at 0:55
  • I think that is a good way to do it. Commented Feb 24, 2016 at 7:10
  • My environment doesn't recognize any of these commands. I'm running on the Nersc Perlmutter supercomputer and I basically just made my account. Any suggestions? Commented Sep 8, 2023 at 21:43
  • what commands? What have you tried, what is your vim version? Commented Sep 9, 2023 at 7:44

I have the same problem with @Jiaming Zhang, no space left on server. So I use df -h to check overall disk usage and use du -sh * to find space of each folder. After I deleted some large directories, it works again.


I had the same error today on a Ubuntu server. It turned out to be no space left on the server. These are the actions I did.

### check the overall disk usage.
df -h

### check the cache folder size.
sudo du -sh /var/cache/apt/archives

### clean the cache.
sudo apt-get clean

### now try again with the file editing and then allocate more space to the disk or clean up the disk.
  • 1
    Welcome to Vi and Vim!
    – D. Ben Knoble
    Commented Jul 3, 2020 at 12:54
  • Thank you sir, you just saved my day! (turned out that my nfs failed to auto-mount, which caused my partition to be overloaded) Commented Dec 6, 2023 at 3:04

You could try using sessions instead of suspending the VM. You could configure your Linux to launch Vim on startup, and your Vim to load the last session.

Anyway, for the following task:

I am running GVim when this happens and do not want to be forced to close it down and reopen a new GVim because I don't want to lose all my open buffers

, you could use the session.vim plugin as it provides the :RestartVim command, which restarts Vim/GVim and restores your windows/tabpages layout.

  • Interesting, but now in these cases, note I am not suspending the VM due to anything happening in Vim/GVim. I am suspending just because of some outside factor, like "I need to reboot the whole computer." The nice thing about VMs is that you can suspend them, reboot the entire computer, and pick up exactly where you left off after the reboot once you start up the VM again. Another "outside factor" might be, "I need to temporarily get rid of this VM because it's eating 6 GB of my memory, and I now need to run this other hog of a VM that also wants 6 GB, and I only have 12 GB." Commented Feb 23, 2016 at 16:07
  • @user62177541 I understand that you aren't closing the VM because of Vim; it was just a suggestion, because I've faced some weird issues after pausing/resuming VMs. Anyway, did you have the chance to try the :RestartVim command?
    – mMontu
    Commented Feb 23, 2016 at 16:29
  • Evaluating it; I don't install plugins into Vim lightly. One issue with it is new dialogs that I do not want and I do not follow a "default editing session" model at all. I always have at least a bunch of sessions, with very different purposes. Do you know how I get rid of this "default session" business? The one session per "--servername" model is kind of OK with me, as long as everything does not have to have a servername. Commented Feb 23, 2016 at 16:36
  • @user62177541 check the g:session_autoload option.
    – mMontu
    Commented Feb 23, 2016 at 16:57
  • On this subject, :mksession is a new one for me that involves no plugins too. That might seem to do what you're talking about better than the plugin, since this is only in these limited situations where I may want this. Commented Feb 23, 2016 at 17:13

Didn't intend to reply to my own question, and this is not necessarily better than the swapfile method, but this works too:

:w then :e!

I initially tried :e as I mentioned but I hadn't tried :e!. And I still have undo history with :e! (tested only on Vim 7.4), just like with the swapfile solution, but...

The negative with this solution of course is that you will lose any unsaved changes since that's ordinarily the purpose of the exclamation, to say "I don't care if I lose changes since the last time saved," so make sure you use :w before doing this. In these swap file error situations, I am always able to save just fine.

The Vim docs mention that :e! is useful when you want to "start all over again" which is kind of the situation here, though we don't want to needlessly throw away undo history:

:e! Edit the current file always. Discard any changes to the current buffer. This is useful if you want to start all over again.
- :h :e!

Because of the unsaved changes issue, I would say the swapfile solution is overall the more advisable, even though :e! is much quicker to type.

A note on Vim 7.3: I believe you would more likely lose the undo history in 7.3 given a similar situation, since 7.4 has seemed to make improvements in reducing the number of situations where undo history is lost. (Thank you to Bram Moolenaar and whoever else helps him make Vim/GVim better!)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.