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.

[bpasero]

I am reconsidering this and reopen given the feedback so far. While I am not entirely convinced this is a severe data loss issue, it is certainly annoying and has aspects of data loss, at least when the user is not entirely aware of what goes on in the editor.

Besides, I now have a pretty good understanding how this could work after thinking more about it: when a file changes on disk and the user decides to not auto reload (either by a new setting or a new dialog with a choice), the file must become dirty to indicate that. Otherwise you might end up with some of the tooling in VS Code such as Git to operate on the file on disk while the file in VS Code has different contents without any indication. If the file is dirty, it is clearer why external tools operate on a different state because we have the same scenario normally when the user makes changes without saving.

We should probably also mark a file as dirty when it was deleted from disk because it is a similar situation.

However, there are downsides and considerations:

• is it obvious enough to mark the document as dirty to indicate what happens? because it is not like the user did any changes, rather the version on disk changed
• what should happen when auto save is enabled? as soon as the document becomes dirty, it may save again automatically overwriting the state on disk?
• how should dirty write prevention work in this case, should we warn the user upon saving that the version on disk has changed and offer the diff editor to compare again with the disk changes?

[minig0d]

I am reconsidering this and reopen given the feedback so far. While I am not entirely convinced this is a severe data loss issue, it is certainly annoying and has aspects of data loss, at least when the user is not entirely aware of what goes on in the editor.

Besides, I now have a pretty good understanding how this could work after thinking more about it: when a file changes on disk and the user decides to not auto reload (either by a new setting or a new dialog with a choice), the file must become dirty to indicate that. Otherwise you might end up with some of the tooling in VS Code such as Git to operate on the file on disk while the file in VS Code has different contents without any indication. If the file is dirty, it is clearer why external tools operate on a different state because we have the same scenario normally when the user makes changes without saving.

However, there are downsides and considerations:

• is it obvious enough to mark the document as dirty to indicate what happens? because it is not like the user did any changes, rather the version on disk changed
• what should happen when auto save is enabled? as soon as the document becomes dirty, it may save again automatically overwriting the state on disk?
• how should dirty write prevention work in this case, should we warn the user upon saving that the version on disk has changed and offer the diff editor to compare again with the disk changes?

Yes, definitely data loss. I'm sure others can chime in with real world examples, but I can't tell you how many times I've done something like generate a new encryption key, pasted it in the file, been tweaking other settings and not hit save yet... POOF. (So not data in the sense that it's usually not the whole file, but key pieces of information.)

What we are asking for is really an extremely BASIC function purely to prevent this unknowing loss of state... I.e. we aren't asking for any kind of long, complex, drawn out solution... It's literally just a dialog with 2 choices

1. allows/permits/proceeds with the reload of the file, which loses all changes I have made locally
2. allows me to keep my dirty file on the screen and ignores the externally changed file.

I suspect there is some variation in how 2. is handled by various editors. I suspect some of them just disable the file watcher until the local copy is saved again (i.e. re-arms once in a clean state). It appears that N++ has a little bit of logic that continues to watch the external file and apparently only re-prompts the user when it detects another change to the external file. This would be great (I think N++ nailed this feature PERFECTLY). I think there may be a slight bit of debouncing to prevent back to back notifications. If N++ is minimized at the time, I don't think the alerts show up until the window is focused again (or if it does the alert window at least isn't in the foreground so it's not obnoxious).

---

To answer your bulleted questions:

• I personally like the local copy, even if my copy isn't dirty, because when I'm viewing a log file, or something that does frequently change, I can just click no and then while I'm looking around in the log it's not constantly jumping
• If autosave is enabled, I'd say KISS and overwrite the remote file... that's up to the editor on their end to detect it... can't solve for everything... I intentionally only enable autosave when I'm using an HTML live preview extension type of thing, otherwise I don't ever turn that on...
• See above the line for this one

---

Here's a second screencap showing it in a locally dirty state and multiple file changes (sorry my coffee hasn't kicked in and can't type for the life of me in the video)

[bpasero]

Thanks for the long explanation. What I do not really understand: how come the file you put in the encryption key is changing on your disk? What other program or user is writing to it? Or are you editing it with another tool as well?

I strongly believe we must make the editor dirty, anything else is just confusing behaviour. Given our save conflict prevention, you would not be able to overwrite the contents on disk though unless you review the changes that happened on disk and make an explicit decision to overwrite, so even auto save would just present you with an error when it tries to save.

See: https://code.visualstudio.com/docs/getstarted/tips-and-tricks#_preventing-dirty-writes

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

You could for example keep in memory the hash of the file on disk and hash of the file being edited. For each edit on editor you can update the editors hash. you can periodically check if the hash of the file oln disk has changed relative to the one vscode has on memory. if the hash of the file on disk changes you can issue a modification. for every save from vscode you update both hashes.

it's not hard, and there are dozens of editors that already do this... don't pretend it's a "current challenge". this is a very long, years even, request.

[gjsjohnmurray]

@minig0d wrote:

been tweaking other settings and not hit save yet

@bpasero, I'd expect this to mean VS Code sees the file as dirty, so it shouldn't get overwritten with a disk-side changed version, right?

[bpasero]

Yes, an editor that is dirty will never be replaced with contents on disk unless you pick File | Revert for example. However, when you try to save an editor where the contents on disk have changed, you will enter the dirty-write flow.

[minig0d]

Thanks for the long explanation. What I do not really understand: how come the file you put in the encryption key is changing on your disk? What other program or user is writing to it? Or are you editing it with another tool as well?

I strongly believe we must make the editor dirty, anything else is just confusing behaviour. Given our save conflict prevention, you would not be able to overwrite the contents on disk though unless you review the changes that happened on disk and make an explicit decision to overwrite, so even auto save would just present you with an error when it tries to save.

See: https://code.visualstudio.com/docs/getstarted/tips-and-tricks#_preventing-dirty-writes

Other people reading / writing to it, not me. It's been a little while since it's happened recently since I'm doing more solo stuff now, but let's just say it's a VERY memorable issue when it happens (which is why there are the few of us here who are very "enthusiastic" about the topic. Not because it happens on a daily basis, but because when it does, it will ruin your day/week/month...

So you're thinking the change could just be to allow it to be seen as "dirty" even if I haven't made any changes (when the external file changes relative to mine)? I'm trying to think through it, but that seems like it would work perfectly... (and it seems like something very easy to enable/disable with a preference for anyone who didn't want it)

[bpasero]

Other people reading / writing to it, not me.

To ask further: is the machine shared by multiple users then that are all working on the same machine editing the same files?

So you're thinking the change could just be to allow it to be seen as "dirty" even if I haven't made any changes (when the external file changes relative to mine)

Yeah and I think it also makes sense conceptually: as soon as the contents on disk change and the buffer that is opened in VS Code is different, the editor essentially must become dirty because that is basically the rule of when an editor is dirty or not: when it contains changes that are not on disk. In this case though its a bit special in that the user did not edit the file and it just became dirty automatically. I think other editors behave similar, I tested this in Sublime Text where it does exactly that.

[Raydir]

Since i was also commenting at the beginning of this i'll try to specify "my" problem with not having an alert, that the file has been changed:

Our scripting-language is processed by an line-by-line interpreter.

The scriptfiles are on the filesystem on a server where they can be edited from different stakeholders.
So when I have open file1.xyz and working on a routine in the upper area, I wont notice changes that are made in the lower parts.

Since it's an interpreter and not a copiled script the mess will be found (or possibly not) only when processing the script.

[minig0d]

Other people reading / writing to it, not me.

To ask further: is the machine shared by multiple users then that are all working on the same machine editing the same files?

So you're thinking the change could just be to allow it to be seen as "dirty" even if I haven't made any changes (when the external file changes relative to mine)

Yeah and I think it also makes sense conceptually: as soon as the contents on disk change and the buffer that is opened in VS Code is different, the editor essentially must become dirty because that is basically the rule of when an editor is dirty or not: when it contains changes that are not on disk. In this case though its a bit special in that the user did not edit the file and it just became dirty automatically. I think other editors behave similar, I tested this in Sublime Text where it does exactly that.

No, usually on remote file systems (SMB/SSHFS/WebDAV once in a while).

I like it.

And glad to see the OP come back and add additional use cases. I'm blocking on some more times it's bit me, but this bug is probably the reason I still use N++ half the time.

[ezel3]

Glad this is reopened.
Personally I would like it to always get a warning when the file I have in my editor is changed on disk, even if I didn't change the editor file myself. This is the same as the Notepad++ behavior. Automatic reloading of a file changed on disk could be handy sometimes, but should be enabled manually for one file only. Notepad++ has a file monitoring option for this (the eye icon in the toolbar).
I would very much like such an improvement to VSCode.

[nxrighthere]

In our case, with enabled auto-save and auto-reload, when a user modifies a file, it is saved immediately. Meanwhile, in the background, our application downloads the file with modifications from another user without any version control. As @minig0d described, VSCode doesn't notify about any changes made to the file from external sources, so it just auto-reloads it. The desired behavior would be to disable auto-reload, so a user would still have the same content. It could work beautifully with built-in conflict resolution, which we would like to use. At least some sort of notification would be great to give the user a chance to save content.

[escaner]

As reference, this is how this feature works in Microsoft Visual Studio.
Whenever the IDE detects one or more externally changed files, it gives you these four options to accept/discard all external changes, or accept/discard them file by file (the window reappears for each file while you kepp pressing Yes/No). Plus the don't bother me with this checkbox. The message is a little different when you had unsaved changes in the editor, but it works the same.

This way it is also quick to accept all modified files when there has been a general update by a version control software.

Also, when you reply "No" to keep the buffer contents, it kepps its dirty/non-dirty state. In Notepad++ it always changes to dirty in this case.

[netizen-ais]

Just an idea, maybe a simple line of code would fix this: Issue a notification on reload using the built in Notifications API

[carehart]

@bpasero you've been a trooper in considering feedback and re-opening the issue recently. Any update on where things stand? Have you heard enough justification to enable such a feature?

[carehart]

If you may need another use case, consider that people use editors for more than code, of course. Perhaps someone has a text-based configuration file open, and some other process (that they run or that runs in the background) changes that file. The whole point of the "don't auto-reload it" workflow (that some of us love about NP++) is that it a) help us detect/know THAT the file change happened and b) allows us to consider what to DO when that change is detected.

For example, I might in such cases save off what I have in the original tab as a new tab, then do file>revert file in the original tab. From there I might be able to see readily what changed, or I might fire up a compare. Or I might in some cases save the changed content to a new file.

But for now, VSCode just sucks the change into the original tab, without any indication at all. And with some config (or code) files, we would NOT readily notice it even happened. Then there's also the "loss" of what we had in that original tab--whether it's content that we "had saved in the past" but then got overwritten on disk, or it may be content we are in fact still editing and had NOT yet saved. Either way, whatever we had in the original tab is lost as soon as anyone/anything modifies the file.

That auto-reload may well be the expected behavior for some. We're just saying it's not the expected behavior for all. And of course in this environment, those who want something can only plead their case and hope to win over consideration. We can't demand or expect things to go our way. If we can't deal with the problem as it is, we can "vote with our feet", as the saying goes. Or at least maybe for some kinds of files.

[nolimitdev]

I agree it is needed feature, I was used on other editor to always ask what to do when data on disk has been changed using 3rd party. Sometimes via 3rd party app I change content temporary and in old editor I answer "Leave old content" so finally refuse new temp. Now VSCode without asking without notification silently changes content (I really hate it). I would be great to add the simple same feature as already mentioned above: https://user-images.githubusercontent.com/14215211/206721906-34916811-7725-444b-8b46-6629be5bc994.jpg Curremt solution that VSCode asks only when file is modified/unsaved is not sufficient.

[yogeshwar-b]

Kind of unbelievable that this issue has been open for more than 6 years, Today I faced the same issue @minig0d has in the screen caps.

[ghost]

Kind of unbelievable that this issue has been open for more than 6 years, Today I faced the same issue @minig0d has in the screen caps.

You must supply 74000 studies showing why this tiny, 30 year old text buffer, should be implemented, and each one of those must have more than 100 signatures each, with at least 40 being from github who have made issues about this. You will submit!!!!!

[Latency]

Yeah, this feature is missing for sure!

If you put focus in a different window, and then come back to VS Code it updates.
Try seeing if you guys can add setting to have some periodic interval be set to auto-refresh the tab-page active.

If the file opened has no changes.. it should be allowed with a preference setting to update automatically.

As sad as this may be, I am having to use SnakeTail to do this very thing.
If we are monitoring to tail a log file in real time, you will quickly see why this feature is needed.

[youyinnn]

The worry about dirty data is unnecessary. No one will actively edit the same file with different editors. Even if that's the case, they are doing the wrong practice and should take their own risk.

If we want to observe an external edition, just mark the file as read-only, and the read-only can't be enabled unless the current changes are saved. What a simple logic.

In other words, once the read-only mode is on, the file should be reloaded right away whenever external changes happen.

[hoffor]

a little confirmation banner such as the one shown for workspace trust would be amazing. i work on files that are often modified by external programs while i have them open, and i need the file to not automatically change while it's open in the editor. notepad++ gives a confirmation popup and while it's very annoying when the file constantly updates and i just want to read its contents, at least it doesn't revert my work without me even knowing sometimes like vscode does.

[Latency]

Just confirmed that neither VS Code or Notepad++ handles it's file I/O properly in RT. This affects features such as tailing log files as example. Default options are used and need to support +RW and Async streams.

You will see update in windows once focused as workaround mentioned in previous comment.

See also 'SnakeTail' as it supports this propperly.