Unsaved file content (at least on Linux x64)

[peter-lyons-kehl]

Type: Bug/Incomplete feature

Summary
VS Code consistently shows an old version of a file (NOT based on any GIT revision). Linux tools show different version (content) of the same file.

Quick elimination question:
Does VS Code require "access times" on Linux filesystems? I have this turned off (but the "modified" file time is up to date, see touch below).

Search existing issues

• YES, I've searched for: "Linux cached file", all pages (https://github.com/microsoft/vscode/issues?page=8&q=Linux+cached+file).

When all extensions are disabled?

• YES:
  

Reproduce
Unfortunately, reproducing this is extremely difficult:

This is happening in Rust programming language source (my fork https://github.com/coop-rs/rust), but I'm sure it's not Rust-specific, nor project-specific. Anyway, I've run x clean, which is Rust build cleanup:

The pure source code takes 2.2 GBs (excluding .git/ and with no artifacts at all):

Hence, could you suggest steps for me to minimize/investigate this, please. Steps/tips with in-depth VS Code and Linux knowledge. As you can see below, I've done some investigation already, but no success yet unfortunately:

• I've rebooted:
  
• I've touch-ed the offending file:
  

I've run the following two commands show that the file, as from filesystem, doesn't contain "assert_covariance" function/text:

sed -n '27,38p;39q' /share/pkehl/GIT/rust/library/alloc/src/collections/btree/map.rs
grep assert_covariance /share/pkehl/GIT/rust/library/alloc/src/collections/btree/map.rs

Shell output is in the right terminal tab/panel:

But VS Code (editor) shows extra code (see the previous screenshot, center panel, highlighted), the code being copied here:

#[allow(dead_code)]
fn assert_covariance() {
...
}

However, that was a temporary code (which I never committed to GIT), and which I'm pretty sure I've undone (possibly with git checkout or git restore instead of editing it in VS Code). But VS Code keeps showing the above obsolete file content.

VS Code version: Code 1.75.1 (441438a, 2023-02-08T21:35:30.018Z)
OS version: Linux x64 6.1.12-1-MANJARO
Modes:
Sandboxed: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz (4 x 2710)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: disabled_software video_encode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	2, 1, 1
Memory (System)	7.65GB (2.45GB free)
Process Argv	--disable-extensions
Screen Reader	no
VM	0%
DESKTOP_SESSION	gnome
XDG_CURRENT_DESKTOP	GNOME
XDG_SESSION_DESKTOP	gnome
XDG_SESSION_TYPE	x11

Extensions disabled

[peter-lyons-kehl]

Updated the above. And narrowed down:

This comes from VS Code keeping that (offending) obsolete file content somewhere. When I

• restart VS Code (again, without any extensions: code --disable-extensions &), and
• I attempt to close that file (map.rs). Guess what - VS Code alerts that the file has been modified - even without any modification to that file since this last VS Code restart:
  

I see that this popup is controlled by Files: Save Conflict Resolution. But it's not the conflict resolution that is the problem. The problem is that VS Code keeps that obsolete file content even between (VS Code) sessions, without alarming the user in any way.

Yes, I do have Files: Auto Save turned off. So, why on earth is this saving the file - or, actually, reading it- from anywhere else other than its location under the project's source tree?

Even worse: This problem is not an one-off. I have noticed similar inconsistent behavior, but I never pinpointed it until now. It probably contributed to several confusing GIT merge/rebase conflicts that I had.

Where and how do I

• disable VS Code from keeping such stealth/hidden versions of files, or
• (if that is not possible), where are they kept? Or
• (if that is not possible), where/how do I get alerted of such inconsistencies (without my having to close all the tabs)?

If you'd like me to investigate, and/or export my VS Code & this project's cached/obsolete file somehow, please

1. provide clear instructions, ideally as Linux commands, and
2. indicate if you'd need to follow up with me, or whether I can "fix" my VS Code project (by closing the offending file tab & re-opening it from the file system) - but, after which, I won't be able to reproduce this anymore.
3. or indicate when you or someone is likely to provide the instructions (if you do want to reproduce this). I'm asking for an approximate timeline indication, because for now I'm keeping this project untouched (so it can be investigated/exported). That means I have to work on a new GIT clone, and that complicates my workflow.

Also, I have Insiders (version: 1.69.0-insider, Commit: 92d25e3, Date: 2022-07-06T23:34:34.229Z) as it's packaged by Arch/Manjaro Linux. Or I can run "Code - OSS" 1.75.1-1 from 9th Feb, 2023. If using these versions (or any other x64 Linux distributions) of VS Code would help to investigate/fix this, then please provide steps on how I extract & "import"/implant the session (with the obsolete/interim source of that file map.rs) from my VS Code to whatever other version.

[peter-lyons-kehl]

~/.config/Code/User/settings.json:

{
    "telemetry.enableTelemetry": false,
    "telemetry.enableCrashReporter": false,
    "extensions.ignoreRecommendations": true,
    "update.mode": "none",
    "files.watcherExclude": {
        "**/target/**": true
    },
    "lldb.showDisassembly": "never",
    "workbench.startupEditor": "none",
    "terminal.integrated.scrollback": 50000,
    "editor.cursorWidth": 10,
    "editor.cursorSurroundingLines": 3,
    "editor.unfoldOnClickAfterEndOfLine": true,
    "bracket-pair-colorizer-2.depreciation-notice": false,
    "workbench.activityBar.visible": false,
    "workbench.editor.wrapTabs": true,
    "editor.fontSize": 18,
    "terminal.integrated.fontSize": 18,
    "window.menuBarVisibility": "toggle",
    "editor.guides.bracketPairs": true,
    "security.workspace.trust.untrustedFiles": "open",
    "terminal.integrated.shellIntegration.enabled": true,
    "window.title": "${dirty}${activeEditorMedium}${separator}${rootName}${separator}${appName}",
    "workbench.experimental.editor.dropIntoEditor.enabled": false,
    "debug.console.closeOnEnd": true,
    "workbench.editor.tabCloseButton": "off",
    "git-buttons": {
        "commit": true
    },
    "workbench.colorTheme": "Default High Contrast",
    "editor.rulers": [
        100
    ],
    "workbench.colorCustomizations": {
        "editor.findMatchBackground": "#00FF00",
        "editor.findMatchHighlightBackground": "#008800",
        "editorRuler.foreground": "#303000",
        "statusBar.background": "#000000",
        "statusBar.noFolderBackground": "#000000",
        "statusBar.debuggingBackground": "#000000",
        "statusBar.foreground": "#ffffff",
        "statusBar.debuggingForeground": "#ffffff"
    },
    "debug.showBreakpointsInOverviewRuler": true,
    "editor.cursorStyle": "block-outline",
    "editor.renderLineHighlight": "gutter",
    "workbench.editor.highlightModifiedTabs": true,
    "rust-analyzer.typing.autoClosingAngleBrackets.enable": true,
    "editor.fontFamily": "'Source Code Pro', 'monospace', monospace",
    "telemetry.telemetryLevel": "off",
    "codetour.recordMode": "pattern",
    "codetour.customTourDirectory": "",
    "bookmarks.keepBookmarksOnLineDelete": true,
    "bookmarks.sideBar.expanded": true,
    "window.autoDetectHighContrast": false,
    "window.restoreFullscreen": true,
    "workbench.editor.enablePreview": false,
    "editor.wordWrap": "bounded",
    "BUFchronicler.ffmpeg-binary": "/usr/bin/ffmpeg",
    "chronicler.ffmpeg-binary": "/home/pkehl/GIT/present_markdown_reveal.js/all_args.sh",
    "chronicler.dest-folder": "${workspaceFolder}/.videos",
    "chronicler.recording-defaults": {
        "flags": {
            "c:v": "libx264rgb",
            "crf": 0,
            "color_range": 2
        },
        "fps": 4,
        "countdown": 3
    },
    "vscrof.directoryStyle": "Linux",
    "vscrof.storageFileTitle": "VsCode - Remember Open Files (vscrof)",
    "tab-groups.relativePaths": true,
    "tab-groups.saveGlobally": false,
    "editor.minimap.enabled": false,
    "sort-tabs.showStatusbarMessage": false,
    "errorLens.statusBarMessageEnabled": true,
    "errorLens.statusBarColorsEnabled": true,
    "errorLens.scrollbarHackEnabled": true,
    "rust-analyzer.cargo.unsetTest": [
        "alloc"
    ],
    "git.detectSubmodules": false,
    "statusBarCustomColor.primaryBkColor": "#000000",
    "statusBarCustomColor.secondaryBkColor": "#000000",
    "breadcrumbs.filePath": "on",
    "breadcrumbs.symbolPath": "last",
    "filePathBar.pathStyle": "relative",
    "vscode_custom_css.imports": [
        "file:///home/pkehl/GIT/scripts_and_configs/vs-code/custom-css/status_bar.css"
    ],
    "GitLink.defaultRemote": "origin",
    "line-length-checker.lineLength": 100,
    "editor.wordWrapColumn": 100,
    "git.openRepositoryInParentFolders": "always",
    "remote.autoForwardPorts": false
}

[lszomoru]

@bpasero, do you mind taking a look at this, as this does not seem to be related to git. Thank you!

[bpasero]

Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/

[peter-lyons-kehl]

I will try with Insiders. In the meantime:

1. Reproducible with every version so far, my current is 1.84.2, commit 1a5daa3a0231a0fbba4f14db7ec463cf99d7768e, date: 2023-11-09T10:50:47.800Z, electron: 25.9.2, ElectronBuildId: 24603566, Chromium: 114.0.5735.289, Node.js: 18.15.0, V8: 11.4.183.29-electron.0, OS: Linux x64 6.7.0-1-MANJARO.
2. Confirming that this is NOT GIT-specific (ignore the fact that my projects are under /share/pkehl/GIT/. The problem continues even after I removed .git from the project.
3. The problem is NOT project-specific. Happening to other projects, too. Basically:
   3.1 Edit a file, BUT
   3.2 Do not save the changes to the file.
   3.4 To check, try to close the (project) window where that file is being edited (for example, with Alt+F4). When attempting to close the project, you get "Do you want to save the changes..." dialog. Do not save, do not close, but Cancel.
   3.5 To check, try to any and all tabs (editors) of that file (for example, with Ctrl+W). When attempting to close the last open editor, you get "Do you want to save the changes..." dialog. Do not save, do not close, but Cancel.
   3.6 Quit whole VS Code (menu > File > Exit, or: Ctrl+Q). This time, there will be NO "Do you want to save the changes..." dialog.
   3.7 Check the file on the filesystem. NOT modified.
   3.8 Start VS Code. The file will have the modified content. Steps 3.4+ can be repeated.
4. This may not be a bug, but a "feature" - but what could it be called, and how could we disable it? Or, better, how could one know which files are in such a state (without attempting to close all editors)?

Potentially related: I also have similar race conditions with VS Code Insiders User settings.json) file. For example, when I just started VS Code Insiders (NOT necessarily the newest version, but the most recent one provided by Manjaro/Arch Linux), I get this (before editing any file, and without modifying any preferences since this VS Code Insiders started). (Of course, that file is separate from non-Insiders ssettings.json).

[peter-lyons-kehl]

CAN reproduce with current VS Code Insiders, as downloaded from https://code.visualstudio.com/insiders/ on December 7th, 2023, file code-insider-x64-1701861306.tar.gz:

❯ cd /opt

/opt 
❯ tar xvzf /tmp/code-insider-x64-1701861306.tar.gz
VSCode-linux-x64/
VSCode-linux-x64/locales/
...

/opt 
❯ ./VSCode-Insiders-1701861306/bin/code-insiders &
[1] 96416

Creating a simple new project, with an empty README.md:

~ is 📦 v0.7.0 via 🦀 v1.76.0-nightly 
❯ mkdir vs-code_unsaved_file_project

~ is 📦 v0.7.0 via 🦀 v1.76.0-nightly 
❯ cd vs-code_unsaved_file_project/

~/vs-code_unsaved_file_project 
❯ touch README.md

Opening that project in Insiders with Ctrl+K+O:

Editing the file, but NOT saving it:

~/vs-code_unsaved_file_project 
❯ #then I quit VS Code Insiders with Ctrl+Q

~/vs-code_unsaved_file_project 
❯ cat README.md 

~/vs-code_unsaved_file_project 
❯ ls -al
total 16
drwxr-xr-x   2 pkehl pkehl  4096 Dec  7 10:06 .
drwx------ 117 pkehl pkehl 12288 Dec  7 10:06 ..
-rw-r--r--   1 pkehl pkehl     0 Dec  7 10:06 README.md

NOW, I see a white circle, both in the application title, left of README.md, and in the editor tab, right of README.md. Once I save the file, both white circles disappear (and the editor tab replaces it with a close x icon). That indicates this is a (new?) feature. What's the tracking issue?

But, the white circle doesn't exist on stable VS Code (at least not on Manjaro/Arch Linux). That confuses people and wastes their time.

Also, we need a feature to provide a list of any and all unsaved files. A white circle is NOT enough, because one may have too many tabs open and under some circumstances only some of the tabs are visible. Is there such a tracking issue/request?

[peter-lyons-kehl]

And/or, please point out where the unsaved content is saved. People need to know this, for example when moving project directories to a new/different machine.

[bpasero]

@peter-kehl I am a bit lost here what kind of issue you see and what the expectations are

Trying to just state out some obvious things:

• if you type into the editor, we show a circle to indicate that you made changes to the file that are not yet saved back to disk. to see all files that are not saved you could optionally enable the "open editors" view by right clicking on the explorer title (we hide this view by default)
• we automatically store a backup of these unsaved changes to a location within $HOME/.config/Code
• this feature is called "hot exit" and is configurable in settings
• as long as you do not save the editor, the contents we show will always match that state and will not show you what is saved on disk
• if you try to save the file while it has changed on disk (we use mtime and size properties of the file for this) we show an error notification (this is the save conflict flow that is also configurable in settings)
• for as long as the editor is not saved, even when you restart, we will restore these unsaved contents unless you acknowledge to save or discard the editor