Make history not remove entries for files that are quickly deleted and then restored

[yume-chan]

Type: Bug

1. Invoke Go To Definition on anything, then invoke Go Back
2. Go Forward is enabled now, but after several seconds, it got disabled.
3. Press Go Back again, the cursor doesn't move

1.mp4

(it can still reproduce with sticky scroll disabled)

VS Code version: Code - Insiders 1.78.0-insider (2da5a00, 2023-04-03T05:21:34.222Z)
OS version: Windows_NT x64 10.0.25330
Modes:
Sandboxed: Yes

System Info

Item	Value
CPUs	AMD Ryzen 5 5600X 6-Core Processor (12 x 3700)
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: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	undefined
Memory (System)	31.91GB (13.41GB free)
Process Argv
Screen Reader	no
VM	0%

Extensions: none

[yume-chan]

2.mp4

When watching the recording again, I found a more possible cause: every time the source control tab blinks loading, the Go Forward button got disabled.

Running Code in debugger confirms that the file watcher keeps notifying the file is deleted and recreated, so navigation stack was cleared, while obviously the file was not changed.

[bpasero]

Is there any clue what and why the files on disk are deleted and re-created? Is Git doing this here for some reason?

[yume-chan]

I think it's caused by turning on this feature in Git.

[bpasero]

I remember that option, but why would a file watcher in git cause files to be deleted and recreated? That would be somewhat strange behaviour for a file watcher, no?

[yume-chan]

This feature can be turned on/off by git config --global core.fsmonitor true/false.

This is what happens in Git file monitor process when pressing the refresh button (captured using ProcMon):

"Time of Day"	"Process Name"	"PID"	"Operation"	"Path"	"Result"	"Detail"
"14:21:47.9703128"	"git.exe"	"17392"	"CreateFile"	"D:\dev\yume-chan\ya-webadb.git\fsmonitor--daemon\cookies\17392-66"	"SUCCESS"	"Desired Access: Generic Write, Read Attributes, Disposition: Create, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Created"
"14:21:47.9704281"	"git.exe"	"17392"	"CloseFile"	"D:\dev\yume-chan\ya-webadb.git\fsmonitor--daemon\cookies\17392-66"	"SUCCESS"	""
"14:21:47.9705237"	"git.exe"	"17392"	"CreateFile"	"D:\dev\yume-chan\ya-webadb.git\fsmonitor--daemon\cookies\17392-66"	"SUCCESS"	"Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened"
"14:21:47.9705544"	"git.exe"	"17392"	"QueryAttributeTagFile"	"D:\dev\yume-chan\ya-webadb.git\fsmonitor--daemon\cookies\17392-66"	"SUCCESS"	"Attributes: AC, ReparseTag: 0x0"
"14:21:47.9705699"	"git.exe"	"17392"	""	"D:\dev\yume-chan\ya-webadb.git\fsmonitor--daemon\cookies\17392-66"	"SUCCESS"	""
"14:21:47.9705860"	"git.exe"	"17392"	"CloseFile"	"D:\dev\yume-chan\ya-webadb.git\fsmonitor--daemon\cookies\17392-66"	"SUCCESS"	""
"14:21:47.9706779"	"git.exe"	"17392"	"NotifyChangeDirectory"	"D:\dev\yume-chan\ya-webadb"	"SUCCESS"	"Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME, FILE_NOTIFY_CHANGE_ATTRIBUTES, FILE_NOTIFY_CHANGE_SIZE, FILE_NOTIFY_CHANGE_LAST_WRITE, FILE_NOTIFY_CHANGE_CREATION"
"14:21:47.9707042"	"git.exe"	"17392"	"NotifyChangeDirectory"	"D:\dev\yume-chan\ya-webadb"	""	"Filter: FILE_NOTIFY_CHANGE_FILE_NAME, FILE_NOTIFY_CHANGE_DIR_NAME, FILE_NOTIFY_CHANGE_ATTRIBUTES, FILE_NOTIFY_CHANGE_SIZE, FILE_NOTIFY_CHANGE_LAST_WRITE, FILE_NOTIFY_CHANGE_CREATION"

It created a new file, so the whole folder was considered changed?

[bpasero]

If the folder is reported as being deleted, we assume that all files within are deleted and thus may do some cleanup tasks such as removing history entries.

The only way out would be to wait a bit and then check again if the file did not come back meanwhile, but that requires a stat call.

Treating as feature request, given this is somewhat bizarre behaviour from either Git or the file watcher we leverage.