Test Hot Exit

[Tyriar]

#101

• Windows @alexandrudima
• macOS @jrieken
• Linux @rebornix

Complexity 5

Overview

Hot exit saves any dirty files between sessions, allowing you to quit VS Code and relaunch it without needing to save the files. There are 4 main parts to this:

a. Hot exit and restore on a window that has a workspace with a folder open
b. Hot exit and restore on a window that has a workspace without a folder open
c. Hot exit and restore on application quit (File > Exit)
d. Recover from crashes by doing a hot exit restore

Hot exit will only occur when the application is quit. This occurs when the all windows are exited (c) or when there is only a single window on Windows and Linux that is closed (a & b, not on Mac as the VS Code main process continues to run until closed via cmd+q).

How it works

• Backups are continually saved in the background, regardless of whether hot exit is enabled or disabled.
• The backups occurs 1 second after typing ends, this buffers the backups and prevents thrashing the disk.
• If hot exit is disabled, exiting the application works just like it did before. This forces the application to clean up the backups.
• If hot exit is enabled, exiting the application will trigger a hot exit as described in the overview section above.
• On launch, the backup restore logic will only be performed if VS Code was not running before (ie. the main process is starting up)
  • Regardless of whether hot exit is enabled, any backups available will be restored. Since clean up is enforced when hot exit is disabled this should only include backups that weren't cleaned up from a crash.
• Backups are stored in <userDataDir>/Backups/<workspaceIdentifier>/<scheme>/<fileHash>.
  • is the user data directory, this differs depending on the OS (the settings.json path is an easy way to find the user data directory).
  • <workspaceIdentifier> is either a hash of the path (for folder workspaces) or a random number (for empty workspaces).
  • <scheme> is either file for text files or untitled for untitled files.
  • <fileHash> is an md5 hash of the file path being backed up.
  • The first line of the backup file contains metadata (file name).
• The file <userDataDir>/Backups/workspaces.json stores all workspaces that should be considered for restore on next launch. Stale workspaces that don't have backups will stick around here until they are cleaned up at next launch.

What to test

Please do some exploratory testing of the feature, here are some cases to cover:

• Empty workspace restore
• Folder workspace restore
• Multiple window restore
• Untitled file backups
• Text file backups
• Testing both when hot exit is disabled and enabled
• Forcing a crash
• Backup files with same string but different casing on Linux (as the file system is case sensitive), make sure there are no collisions
• Backup a file on Mac/Windows, change case and see if it's restored
• Ensure hot exit plays nicely with files.autoSave and files.autoSaveDelay
• Ensure hot exit plays nicely with windows.reopenFolders
• Non-ASCII characters get restored
• Backed up files are deleted between sessions
• Workspace is deleted between sessions
• Files are getting restored to their correct groups