microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
163.89k stars 29.17k forks source link

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

Open yume-chan opened 1 year ago

yume-chan commented 1 year ago

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

https://user-images.githubusercontent.com/1330321/229702958-a47d1f45-0f26-4d7b-bd71-eef927d817d0.mp4

(it can still reproduce with sticky scroll disabled)

VS Code version: Code - Insiders 1.78.0-insider (2da5a0024fe2ca407f741f19340f1a10f4d692af, 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 commented 1 year ago

https://user-images.githubusercontent.com/1330321/229719246-d1fd9427-bb11-40c5-8a03-7fd9aff49afb.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 commented 1 year ago

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 commented 1 year ago

image

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

bpasero commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.