[vim/vim] Vim file-save strategy breaks file-watching applications (Issue #15733)
Tim Holy
Steps to reproduce
I'm not a vim user so this is only an indirect report (see original: timholy/Revise.jl#841).
@acertain, @rafaqz feel free to chime in with additional detail.
Expected behaviour
My understanding is that the sequence of operations when vim saves a file is:
- rename file to backup
- write & fsync new file
- remove backup
Unfortunately, for any application that performs file-watching, it may be triggered between 1 and 3. I'm sure I'm naive about the potential problems it might cause, but it would seem that a more robust approach might be:
- write & fsync to a temporary file
- rename the temporary file to the original filename, thus "displacing" the original file
Version of Vim
?
Environment
?
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
This is configurable using the 'backupcopy' option. I suggest to try this.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Nir Lichtman
Very interesting, I actually noticed this behavior a couple of days ago and I wasn't sure why it specifically occurred with Vim, but this clears it up.
Opened a PR to address this issue by changing the default value of bkc: #15739
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
John M Devin
I've encountered this issue with a few LSPs before as well, where they will stop working on filesave (e.g. here: (link)). I can't say whether changing it as a default would have any negative effect, but it would certainly be useful. I hope someone more knowledgeable than me has the time to look into this.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gary Johnson
> Very interesting, I actually noticed this behavior a couple of days ago and I
> wasn't sure why it specifically occurred with Vim, but this clears it up.
>
> Opened a PR to address this issue by changing the default value of bkc: #15739
In any case, you most definitely do not want to change the default
value. There are countless users who depend on Vim to work
consistently, and there are few things as frustrating as a tool that
you suddenly notice is working differently without knowing why or
when it changed. I love that I can depend on Vim to work the same
after an update as before.
Regards,
Gary
vim-dev ML
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Nir Lichtman
In most cases I would agree that changing the default behavior is generally a bad idea, but this case is special since the current default is 'auto' in most cases, and 'yes' in a specific scenario of Unix/Vi mode.
The docs describe 'auto' as choosing the best option between 'yes' or 'no' so even today it shouldn't be relied by users as whether it chooses in this case to use a 'yes' or 'no' logic (and in fact in the code it changes the strategy anyway according to some edge cases like file links - ref buf_write function bkc logic).
In general file systems should take roughly the same time to rename or copy files so this change would not affect that factor as well.
Thus, IMO this is a special case in which switching the default would have much more benefit since current behavior is very confusing for a common use case of code editing with build-on-watch setups, since like me a day ago, probably many people are not aware of the bkc option or are aware and don't draw the connection between it and how Vim affects watch.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
John M Devin
In any case, you most definitely do not want to change the default value. There are countless users who depend on Vim to work consistently, and there are few things as frustrating as a tool that you suddenly notice is working differently without knowing why or when it changed. I love that I can depend on Vim to work the same after an update as before.
I agree that vim shouldn't change defaults, but only by following it with, "without a major version increment or other good reason" Breaking changes is what major increments are for, and @nir9 seems to think the reason is good here. The default setting of 'backupcopy' currently breaks tools of users, like me (see link in my previous comment), leaving them to investigate a pretty obscure error with almost no indicator of the problem. I was lucky enough that a different vim user had already had the same exact problem, otherwise I believe I would have simply had to choose between vim and the tool for my use case.
I don't know whether changing this specific default would be harmful, or to who - and I don't assert my own lack of knowledge about this as evidence, so I can't argue in favor of changing the default. But I would appreciate anyone more knowledgeable than me, who can speak to the issue, weighing in.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Gary Johnson
all.
Regards,
Gary
vim-dev ML
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Aliaksei Budavei
I imagine that there are and there will be not one but a few
options whose default values are poor choice for a random
$ENVIRONMENT. In the absence of an ftplugin for it,
wouldn't it be more consistent for the people that care
about it and are in the know to maintain a public list of
such options and suggested values in $ENVIRONMENT.txt?
So that interested users can do what they will with it in
their own configuration files or try third-party plugins.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
D. Ben Knoble
A couple of thoughts:
- Using the default
bkc(autohere on macOS) hasn't broken eitherentr(a file watcher) or any of the LSPs I use (via ALE as a client). - Is there a way to make a better warning/error message for this (in tools or Vim), or otherwise document something to point more people towards
backupcopy? This might be in addition to or instead of changing the default.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Nir Lichtman
@benknoble It is probably statistical in some cases/setups, for example I have worked with React Create App up until recently on a MacOS environment with Vim and I remember that quite frequently it would not refresh the changes after I saved and I had to make another small change so it would refresh. I assume it's related in the end to this option but I haven't dug deep into it.
About making a warning/error, I think that would not be trivial since the question is asked, how does it detect a situation in which this problem occurs and show the user an error.
About the PR of changing the default bkc value, I have recently closed it (see #15739 for more info)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
Closed #15733 as completed via 5bcfb5a.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.