Allow to configure editor auto reload behaviour

[dmlemos]

VSCode Version: 1.10.2 OS Version: macOS 10.12.3

Steps to Reproduce:

1. Open editor
2. Modify a file in your git repository, but don't save it
3. Checkout a different branch that touches the same file
4. Go back to the editor and try to save
5. ERROR: "Failed to save 'file1': The content on disk is newer. Click on Compare to compare your version with the one on disk."

Personally I would like to see the files being reload from the disk every time without prompt. With git I don't have to worry about losing history. Similar to how SublimeText works. When the files change in disk (ex: change of branches), they get automatically reloaded, independently of their current state in the editor. I prefer this behaviour, rather than having to confirm reloads.

With that said however, there must be options for all the use cases. Many people prefer to be notified of changes in their files! Suggestion to add an editor.autoReload parameter in order to control this behaviour. Possible values:

• Always - reload from disk without prompt
• Confirm - show a prompt confirmation to either accept or discard the changes
• Backup - show the file with the new changes automatically, but always backup the old state to 'filename.bak'
• Never - current behaviour?

Evolved the idea from @rmunn on #23043 issue. Decided it was best to create a separate issue for this.

EDIT: Made it clear that it is mandatory to implement this feature with all the use cases in mind, and added new options.

[marcelocantos]

For unedited files, VSCode's behavior is already optimal (auto-reload without asking) bar the suggested improvement in #23043.

However, always is dangerous if there are unsaved edits. I guess if people want to opt in to this, they're their tears to make, but I'm not sure this is such a good idea.

[offero]

I sometimes get this message but there is no difference between what is on disk and what is in the editor. Maybe I added and removed a character, but there is no difference.

[bpasero]

There are related issues that ask for a confirmation dialog when files change on disk: #14298, #20876

Let's keep this issue around for the desire to have a setting to always overwrite a file if it changed on disk even if it is dirty.

[WilliamStone]

Comment from closed issue #41250, which presents a scenario that auto-reload behavior differs by file path pattern. So it may be appropriate for auto-reload option to set behavior not globally, but based on file path pattern, e.g. D:\Dropbox\**\*.* File path pattern can also cover file-type option scenario by file extension, e.g. D:\Java\**\*.java

[maximelafarie]

Is there anything new? I'm having the same problems. For example, I make an error that will be underlined, then to make it go away I have to go to another file tab, then back to the file tab where the error was detected to get vscode to refresh the entire file.

Is there an option to disable the cache if there is one, or to automatically trigger a new file check? 🤔

[Raydir]

@bpasero you wanted to know why it is important to get a notification if a file is changed outside.

As for me (and my related users) it is absolute necessary to get a feedback when someone/something did change the content of the file since many of our source files are not compiled and not checked in in something like e.g. GIT.

Example: Some of our scripts are textbased and it happens that you work on a file for hours. If i'm working on a file and go to the toilet or gettin a coffee i'd like to know if some part of my code has been modified meantime.

Perfect would be if one can see the changes alike when you compare it to the content in your clipboard

So my wish would be to have a setting to get a message if changed, check the changes in the diff-view and agree or decline the changes.

[bpasero]

My current challenge with this feature is that I cannot easily distinguish a change done in the editor (VSCode) from a change done externally. If someone has suggestions how to distinguish these two, please speak up. I would never want to show the confirmation to show up for changes done by the user in the editor.

Another question is wether this notification should show up for tabs that are opened but not active. I would find it quite disturbing to get spammed by notifications for each file that was changed if it is not the active file I am seeing.

[Raydir]

@bpasero I agree with you on your latest point - the message should pop up when you get focus to a file and it has been changed outside.

[bpasero]

@Raydir is that true though? What if you have focus in the editor and trigger the command to pull from Git and changes come in, would you not want to see a notification then too?

[Raydir]

For me it is only needed when i am working on a file. if you get the file from e.g. GIT you want to get the changes / latest version. That's not the same i'd say.

If you pull from GIT and due to this you are looking your changes it's your own fault... But you are only loosing work if someone is changing the SAME file while you are working on it.

Think about this one: You have thousands of lines of code finished and now you are do some refactoring at the beginning of the file. If someone is changing content at the bottom you wont even notice that it has been changed at the moment.

[bpasero]

@Raydir but how do changes to a file come in if not by explicit decision from you? It is not like 2 people are working on the same file and the changes come in without you doing anything unless maybe you actually had a shared remote file system that constantly pushes changes to your disk?

[rmunn]

@Raydir - This is a little bit off-topic in this bug discussion so I won't belabor the point beyond this single comment, but this phrase causes me serious concern:

many of our source files are ... not checked in in something like e.g. GIT.

I would urge you to fix this situation as soon as you can. You are working without a safety net, and causing yourself unnecessary pain by doing so. Using Git as a programmer is like using saves when playing a video game. Yes, you might be able to get by without it... but then there are some mistakes you can't recover from, and you're in danger of having to start from scratch if your mistake is bad enough. A git commit is like saving your game: it gives you a checkpoint that you can always go back to if you need to. The peace of mind that comes from knowing that I can't lose more than the past few minutes of work is immense. If you have "thousands of lines of code" as per your previous comment, and it's not checked into Git, you could lose ALL of that with just a single careless mistake. Please don't do that to yourself: start using a DVCS (Git, Mercurial, whatever) as soon as possible so that you have a safety net.

[siran]

My current challenge with this feature is that I cannot easily distinguish a change done in the editor (VSCode) from a change done externally. If someone has suggestions how to distinguish these two, please speak up. I would never want to show the confirmation to show up for changes done by the user in the editor.

Another question is wether this notification should show up for tabs that are opened but not active. I would find it quite disturbing to get spammed by notifications for each file that was changed if it is not the active file I am seeing.

Just an idea, but you could probably cache the modified timestamp and see if it changes.

You could do this check everytime a file tab is focused (I agree it can be disturbing otherwise). Yet, other editors notify you on for all opened files (I suppose there is a timer somewhere). Both behaviors can be useful.

[bpasero]

Just an idea, but you could probably cache the modified timestamp and see if it changes.

Yeah we do that already but in certain file systems this has proven to not be reliable (e.g. network shares).

You could do this check everytime a file tab is focused

I think that does not cover the case of you invoking a keybinding to pull in changes from git and the active file changing. There is no focus loss in that case, yet you probably still want to be notified.

[Raydir]

@rmunn You probably should know that that is not really my decision (I'm just the person that tries to reduce the problems related to this) and that I DO know what e.g. GIT is or what would be the benefits. This part of source is customer related and I can't just change that situation since this is a 30 years old situation. We DO backups of those files. But not with something alike GIT and i can't controll the backup if the customer is doing hardware maintenance himself...

@bpasero
Those files are on a network share and there IS the possibility that more than one person is working on the same file - but not intentionally. And exactly THIS is the problem. So the problem is, that one person is working on a feature and another one tries to fix a problem related to that file. Et voilà...

If you don't have a file lock alike Visual SourceSafe did n'or a message like Notepad++ does, you wont notice and you can't react to or decline the change.

[Raydir]

@bpasero if the editor would open files exclusivly (lock) the problem would not exists tho.

[bpasero]

Those files are on a network share and there IS the possibility that more than one person is working on the same file

Wow, that is a crazy work environment...

Even if we implemented a notification prompt, file events over network shares are so unreliably (actually not working) that it would probably not work even if we implemented this with our file watching infrastructure today.

[Raydir]

For me I will leave this point since I guess I made my point clear...
If the feature is not possible so should it be. Kind of strange tho, that the other guys that did wish this feature are not commenting again.

To clearify... it's not our base source that is "open" it is the customer specific part that can be implemented/changed to customer needs. The execution is server based. To change a file the customer / project leader/ customer dev has to connect to the server - with a networkshare or RDP or what-so-ever.
Even when you open the file from RDP the problem still persists since the file can be opened by several peoples at the same time. So not the network-share itself is the problem and not the case of this discussion.

@bpasero i won't comment the "crazy work" environment...

[bpasero]

@Raydir but in that environment you constantly must have conflicts, or not? I only see this working if the file could actually be locked by you and then no-one else can make an edit until you release that lock?

[bpasero]

Also, I have not seen an editor/ide that prompts you on a change and offers you the ability to diff your changes with the ones on the server. So if you see a prompt and you get asked to either drop your changes or overwrite the remote ones, what do you do in that case without knowing what the changes have been?

[Raydir]

No we don't since normally it is the project leader together with the customer. When building new processes there are specific files that handle events. Those can be problematic when several issues are implemented by different peoples.

As said before - to open a file exclusively like possible in e.g. Textpad would be sufficient. The point with the "diff" would be a perfect addition - if not possible that's not a killer criteria for me.

[BillDenton]

This is how Visual Studio 2017 handles files changed in the background: This is the kind of behaviour I would like to see Visual Studio Code.

[arnaalg]

We have encountered several situations where a promt like shown above from Visual Studio 2017, or below here from NotePad++ or UltraEdit, would be very welcome.

NotePad++

UltraEdit

1. Settings- / project-files that are written to by open applications while being edited in VS Code: For instance during FPGA development. We often work with manual modifications on *.qsf-, *.sdc-, *.cof-, *tcl-files in an editor at the same time as we run compilation, synthesis, timing-analysis, simulations or other operation from the open Quartus application. Quartus writes it's own things to the same files. For instance we could imaginge changing the paths of the source files in the *.qsf file, then Quartus overwrites these paths with the old ones without any notice. You check in the file, and the build server builds the project using the wrong source files.

2. Working with VHDL files in VS Code and compiling in Quartus. If compilation fails you jump directly to source by clicking on error message output in quartus. This typically opens the internal text editor of Quartus. Apply changes here, save file and re-compile. This scenario might not be as dangerous since the changes are manually done by yourself in another editor, but it would be super useful to get that promt as a confirmation/reminder. Don't forget that there might be enough coffee-cup refills or pee-breaks between these events to forget what you were doing.

[arnofly]

Same request than @BillDenton or @arnaalg

We can imagine that this option works like this: You split your file on the same window in VS Code. So, you have 2 views of the same file with one tab is active. The active tab could be autorized by the user to auto refresh the file if this one is modified by an external program (I mean with or without a prompt, depend user prefs). The inactive tab(s) keep the old version(s) of the file.

I instinctively tried to do this with VS Code 1.30.2, but the software refresh all views.

[BarryBo]

I just had data loss due to this. This would have worked in VS2017, but didn't in VSCode... I had VSCode open with a particular file open, but saved to disk. I then used 'git checkout --' to undo the changes in the filesystem. I expected the VSCode in-memory version of the file to stay around while I did git operations underneath. I then planned to save the VSCode version on top of the filesystem version.

In VS2017 I get a warning about the file changing underneath the editor and have a choice of whether to reload or not.

In Code, I get no warning, and the automatic reload lost my changes.

[ezel3]

I lost 4 hours of work because of this. I was working on a program on a Linux box, and copied the previous version back with WinSCP for inspection. Instead of asking if I wanted to load the changed version VSCode did so all by itself. All my work was overwritten. This is not funny and absolutely not intuitive. Please add a possibility to disable this behaviour or add a prompt like BillDenton and arnaalg described above.

[tstauffer]

What is the resolve here? I agree with so many others that this needs to work at least as well as Notepad++. this is very frustrating

[escaner]

Could we have this feature asking whether to reload the files or not, please? Actually this prompt should also appear when another vscode instance modifies a file and both buffers are not synced. I even prefer having to confirm a "git pull" over the risk of losing work on an automatic load of an externally modified file. This feature has saved me several times over decades of software development in other editors and I do not consider an editor that changes files without my consent fit for serious work.

[tstauffer]

one thing i have done to mitigate the issue is install LocalHistory xyz. in this way, you can still get back to what you had. To be quite honest, this even happens in my regular git development areas and I have to rely on the IDE's local change repo to save my bacon at times.

[Encoder42]

Just started using VSCode which has really great features and customization possibilities. Thanks for releasing it as open source! Soon I discovered the automatic reload without notification or the possibility to keep the current document without reloading. This seems very critical and dangerous to me and could prevent me from using VSCode as my new favourite editor.

Blocking pop-up windows (as used by many other editors in such a case) are very annoying (especially if updating many documents, e.g. using git) and would disturb the nice user experience of VSCode.

I would suggest a concept as used in Geany (www.geany.org) which inserts Information in the document window and allows the user to choose what to do without blocking. (E.g. you can postpone the choice and edit another document first)

Geany 1.34

A nice configuration option for VSCode could be:

• "editor.fileReload": "auto" same handling as today with automatic reload without notification

• "editor.fileReload": "notify" automatic reload as today but with geany style information in document window and marking of tab. The info box could allow to:

  • [Undo] - restore previous editor contents
  • [OK] - acknowledge change

• "editor.fileReload": "ask" marking of document tab and geany style information to allow the user to choose what to do:

  • [Reload] - reload document from disk
  • [Overwrite] - write current editor document to disk
  • [Diff] - show differences between current document and file on disk
  • [Cancel] - do not read or write disk, keep editing current document