"Start Debugging" is auto-saving open files even for unchanged files

[spacem]

Since updating today now when I try debugging visual studio codes saves the active file (even though it already is saved) this causes my gulp script to see the change and rebuild/restart node which means node does not show up in the attach to process list. I have "files.autoSave": "off" in my config.

• VSCode Version: 1.10.1
• OS Version: Windows 10

Steps to Reproduce:

1. Open a js file
2. Click the green play button in the debug view

[isidorn]

@spacem yes this is how start debugging is behaving by design. We could introduce an configuraiton to not autosave on start.
@bpasero shouldn't the save operation be a no-op when there are no changes?

[bpasero]

@isidorn I suggest you add a breakpoint here to find out why it saves, the reasons are explained in that location: https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/services/textfile/common/textFileEditorModel.ts#L600

[bpasero]

Another case where a save can cause something to happen is when a save participant is installed that wants to change the file (even if it is not dirty).

[adelphes]

This issue has broken my incremental build feature.

Saving clean files when launching a debug session is not a good idea. Like many designs, my debugger tests whether a rebuild is necessary by comparing the file times of the source files with the file times of the output. If the source files are newer, a rebuild is necessary.

Performing a save on every debug session causes the source files to have a later timestamp, forcing a rebuild every time.

Can you revert this back to the original behaviour.

[alemhnan]

Also not sure if it's related, but now nodemon restart the server when I start to debug. The net result is that I get a timeout error everytime now (related bug #21783)

[isidorn]

@bpasero what changed is that now I am explictly calling the workbench.action.files.save due to #19415
In textFileEditorModel line 600 all those fields are true because the save action wants to trigger all external file watchers. And that is bascially the difference between the workbench.action.files.save and calling saveAll on the fileService as we had done before.

@adelphes @alemhnan @spacem yes, we will revert back to the original behavior and you can pick up the fix in tomorrow's vscode insiders.
For now I am not sure if this should be treated as a candidate for the recovery build. @bpasero opinion?

[bpasero]

@isidorn what about we introduce another save action which is "Save if Dirty" and all it does is to be different around this line where it forces a write even if the file is not dirty? People that do not want our current behaviour for saving could even remap the Ctrl+S to that command.

[isidorn]

@bpasero sounds good to me. I can look into it later tonight.

[isidorn]

@bpasero I introduced a new Save if Dirty action, currently I registered as a regular action so it appears in the command palette which I am not sure is the best.

Adding candidate label to discuss if this should be a candidate in tomorrow's standup.

@adelphes @alemhnan @spacem tomorrow's insiders will contain the fix for the issue. Can you please try it out. Thanks