-
-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(developer): prevent simultaneous opening of the same project by two processes #13341
fix(developer): prevent simultaneous opening of the same project by two processes #13341
Conversation
…wo processes There is a race condition where two processes may both attempt to open the same project file. This appears to happen, for example, if an author double-clicks on a single-click shortcut, launching Keyman Developer twice in quick succession. This fix adds a .lock file which is deleted automatically on close of the project or on normal or abnormal process termination. If a second process encounters the .lock file, it will simply open the welcome view instead of attempting to open the project. Fixes: #11584 Fixes: KEYMAN-DEVELOPER-1PR
User Test ResultsTest specification and instructions Test Artifacts
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Maybe we add .lock
to the .gitignore
file in the keyboards repo
Review: I want to use a private appdata folder with hash of project filename (lowercased) instead of the current design of a .lock file next to the .kpj file. This will be less confusing for keyboard authors because the .lock file comes and goes and is never readable anyway. |
For the project lock files, instead of using a filename in the same path as the project file, with a .lock extension, use a hash of the project filename in the Keyman Developer appdata folder, to avoid confusion and conflict in project folders. Fixes: #11584
Test ResultsI tested this issue with the attached KeymanDeveloper"18.0.199-beta-test-133341" build(25/02/2025) on Windows 10 and 11. Here I am sharing my observation.
|
LoadGlobalProjectUI(ptUnknown, TikeCommandLine.StartupProjectPath); | ||
if LoadGlobalProjectUI(ptUnknown, TikeCommandLine.StartupProjectPath) = nil then | ||
begin | ||
raise EProjectLoader.Create('Project is already open in another process'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the lock file get left behind if the user reboots/shuts down while Keyman Developer is open?
I get frustrated by Android Studio when it does this. They include the path of the lock file to remove, so the user can manually remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two things:
- The lock file is automatically deleted on close. It would take a hard reset for it to remain
- Keyman Developer will attempt to recreate it even if it exists -- so it does no real damage to leave it there in any case (and it's out of the way of the user now so it's really very harmless).
Changes in this pull request will be available for download in Keyman version 18.0.202-beta |
There is a race condition where two processes may both attempt to open the same project file. This appears to happen, for example, if an author double-clicks on a single-click shortcut, launching Keyman Developer twice in quick succession.
This fix adds a .lock file which is deleted automatically on close of the project or on normal or abnormal process termination. If a second process encounters the .lock file, it will simply open the welcome view instead of attempting to open the project.
Fixes: #11584
Fixes: KEYMAN-DEVELOPER-1PR
User Testing