0

At seemingly random moments, Vim litters my working directory with backup files like foo.bak, despite that nobackup is set. Note that Vim does not litter with foo~ (as it would if backup were set), but with foo.bak. Five questions:

  1. Why is Vim littering my directory?
  2. How does Vim decide when to litter my directory?
  3. How can I tell Vim not to litter my directory?
  4. For experimentation, how can I provoke Vim to litter at a moment I choose? (In other words, how can I reproduce the bug?)
  5. Why is the backup named foo.bak instead of the expected foo~?

The questions are interrelated, of course.

8
  • 1
    @filbranden :set bex? tells me backupext=~. This is why I do not understand the reason Vim is emitting the file foo.bak at seemingly random intervals. If I :set backup, then Vim will produce foo~, as one would expect. Apparently, the foo.bak comes from somewhere else.
    – thb
    Oct 27 '21 at 13:34
  • 1
    Is it possibly a Vim plug-in that you have that is performing some operation on your file in background? Perhaps some kind of auto-formatting plug-in? I guess it's likely that it's something other than Vim itself which is producing those backups... But it could still be triggered by Vim, since it seems to be happening to files you're editing.
    – filbranden
    Oct 27 '21 at 17:02
  • 1
    @filbranden That's a good idea. I had not thought of that. Unfortunately, I do not see the string "bak" in the plugin files. I had been hoping that someone here would reply, "Yes, Vim often litters my working directory, too; here's why." Since no one has, either I'll have to dig the answer out of Vim's source code for myself or else wait until someone happens to arrive here with the answer. Meanwhile, thanks for taking the time to engage with my question. I appreciate it.
    – thb
    Oct 27 '21 at 18:15
  • 1
    Try using strace: strace -f -s 1024 -tt -o ~/vim-strace.txt vim, then reproduce the problem. Inside the ~/vim-strace.txt file you'll find a line where it's opening foo.bak (for writing) and you can see the PID of the process that did that. Look up for an exec (might be execv or execl etc.) that shows what command was executed in that process. That might give you a hint...
    – filbranden
    Oct 27 '21 at 18:26
  • 1
    Let us continue this discussion in chat.
    – thb
    Oct 27 '21 at 20:20
0

A few days later, I answer my own question. My answer isn't a very good answer. It's only a workaround and I have tested it only tentatively and only on a Debian 11 bullseye platform (so the answer probably wants adaptation for use on Windows); but since no other answer has yet been posted here it is.

To work around the problem as I have done, one should do the following.

First, make a new directory $HOME/bak (if it does not already exist) and subdirectory $HOME/bak/vim (this should be new)—where $HOME is your home directory.

Second, add this line to the per-user configuration file $HOME/.vimrc:

set backupdir=$HOME/bak/vim

(Again, substitute the proper value for $HOME. For example, my username is thb, so I have added, set backupdir=/home/thb/bak/vim.) If $HOME/.vimrc does not exist, then create it and add the above line.

Third, if Vim is running, exit and, if you wish, restart.

Why does this solution work? Actually, I am unsure that it does work, but since I have implemented it a few days ago, I have not seen the problem to occur again. The intent is to funnel backups, including spurious backups, into a single directory that keeps the backups out of the user's way. However, once I had put the funnel in place, the problem seemed to disappear altogether for some reason. No spurious backups seem to be going into the funnel, but only ordinary backups explicitly requested by set backup. No spurious backups seem to be going anywhere, whereas I used to encounter one or two spurious backups a day.

It is as though the funnel had frightened the spurious backups away.

I do not know the reason the funnel has frightened the spurious backups away (if indeed it has), since I still do not know why the spurious backups started haunting me in the first place. I do not doubt that a logical reason exists, only I do not know what the reason is.

Anyway, in case this workaround is useful to anyone, there it is.

CONJECTURE

I used to encounter the problem occasionally (once or twice a month) on Debian 10 buster. After installing Debian 11 bullseye, the frequency increased to once or twice a day, as I said. I have never been able to reproduce the problem at will.

I conjecture therefore that the problem descends from a race condition: when I am relaxed and not focusing on reproducing the problem, some quick, unconscious sequence of keystrokes of mine is sometimes overloading an internal buffer of Vim's before Vim can clear the buffer. Perhaps it's when I type :w plus something else immediately before or after. I don't know, but whatever it is panics Vim, upon which Vim, to be safe, writes a backup to avoid losing the buffer.

If the conjecture is right, then setting aside a separate, safe backup directory seems to have soothed Vim's panic. Or perhaps, once the backupdir configuration is set, Vim internally diverts onto a different, quicker codepath that outpaces my keystrokes. Hence, no panic and no spurious backup.

DIAGNOSTIC

In chat elsewhere, @filbranden has given a potentially useful procedure. I have achieved no concrete result from it but the procedure might prove of use to someone else.

Try using strace: strace -f -s 1024 -tt -o ~/vim-strace.txt vim, then reproduce the problem. Inside the ~/vim-strace.txt file you'll find a line where it's opening foo.bak (for writing) and you can see the PID of the process that did that. Look up for an exec (might be execv or execl etc.) that shows what command was executed in that process. That might give you a hint...

UPDATE

Three weeks later, I can report that the above-described workaround has worked flawlessly.

I do not know why the workaround works, but with the workaround in place, spurious backups apparently no longer occur at all.

2
  • 3
    How did you search the plugin files? The OS might distribute customized vimscripts, so check all the directories in :set runtimepath? for possible culprits.
    – D. Ben Knoble
    Oct 30 '21 at 12:11
  • I have searched the plugin files by grep -r bak $DIR. Now on your advice, I have searched all the runtimepath directories. I have also searched Vim's source (version 8.2 as distributed by Debian). The string "bak" occurs in several spots but, upon investigation, none is likely the culprit that I can see.
    – thb
    Oct 30 '21 at 18:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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