-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
LaunchServer: Return error response when handler program doesn't exist #8120
Labels
Comments
gunnarbeutner
added
enhancement
New feature or request
good first issue
Good for newcomers
labels
Jun 17, 2021
I will look at this since I am working on #8121 as well. |
bitwitch
pushed a commit
to bitwitch/serenity
that referenced
this issue
Jun 21, 2021
This commit gets rid of hard coded file handlers in Launcher.cpp in favor of using values in the LaunchServer.ini config file. The previous commit adds checks for the existence of handler programs while registering handlers. This commit takes advantage of that and ensures that LaunchServer will not attempt to open a file with a nonexistent program and can properly report failure before spawning a new child process. Resolves SerenityOS#8120
DMaroo
pushed a commit
to DMaroo/serenity
that referenced
this issue
Jun 22, 2021
This commit gets rid of hard coded file handlers in Launcher.cpp in favor of using values in the LaunchServer.ini config file. The previous commit adds checks for the existence of handler programs while registering handlers. This commit takes advantage of that and ensures that LaunchServer will not attempt to open a file with a nonexistent program and can properly report failure before spawning a new child process. Resolves SerenityOS#8120
DMaroo
pushed a commit
to DMaroo/serenity
that referenced
this issue
Jun 23, 2021
This commit gets rid of hard coded file handlers in Launcher.cpp in favor of using values in the LaunchServer.ini config file. The previous commit adds checks for the existence of handler programs while registering handlers. This commit takes advantage of that and ensures that LaunchServer will not attempt to open a file with a nonexistent program and can properly report failure before spawning a new child process. Resolves SerenityOS#8120
kleinesfilmroellchen
pushed a commit
to kleinesfilmroellchen/serenity
that referenced
this issue
Jun 24, 2021
This commit gets rid of hard coded file handlers in Launcher.cpp in favor of using values in the LaunchServer.ini config file. The previous commit adds checks for the existence of handler programs while registering handlers. This commit takes advantage of that and ensures that LaunchServer will not attempt to open a file with a nonexistent program and can properly report failure before spawning a new child process. Resolves SerenityOS#8120
aatosmajava
pushed a commit
to aatosmajava/serenity
that referenced
this issue
Jun 25, 2021
This commit gets rid of hard coded file handlers in Launcher.cpp in favor of using values in the LaunchServer.ini config file. The previous commit adds checks for the existence of handler programs while registering handlers. This commit takes advantage of that and ensures that LaunchServer will not attempt to open a file with a nonexistent program and can properly report failure before spawning a new child process. Resolves SerenityOS#8120
metmo
pushed a commit
to metmo/serenity
that referenced
this issue
Jul 1, 2021
This commit gets rid of hard coded file handlers in Launcher.cpp in favor of using values in the LaunchServer.ini config file. The previous commit adds checks for the existence of handler programs while registering handlers. This commit takes advantage of that and ensures that LaunchServer will not attempt to open a file with a nonexistent program and can properly report failure before spawning a new child process. Resolves SerenityOS#8120
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When opening a file via LaunchServer, but the registered handler for the program does not exist, the launch will quietly fail with simply debug out:
This is due to the fact that the exec fails in the child process, which cannot easily communicate that back to the parent process (due to
posix_spawn
's architecture). If the failure could be properly reported by LaunchServer, its clients could properly report an error (e.g. with a MessageBox for FileManager or a non-zero return code foropen(1)
).The text was updated successfully, but these errors were encountered: