-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Make sure args.getSettingsPath() returns the correct directory #3956
Conversation
Not sure if this is a 2.3 candidate, because I am not able to test it. The fixed bug is obvious though. |
a53a65b
to
5b1cbe8
Compare
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.
Seems reasonable to me. Other opinions?
Ok, then let's merge and hope for the best ;) LGTM |
The changes need to be merged to main now. Non-trivial merge conflicts. |
Yes, it looks like the call to Sandbox::checkSandboxed() has been lost in main. I think that is wrong, right? |
Thanks! |
… introduced by mixxxdj#3956 This is a bandaid. The reintroduced issue of settings path access before checking the sandbox will be fixed in a follow up PR
… introduced by mixxxdj#3956 This is a band aid. The reintroduced issue of settings path access before checking the sandbox will be fixed in a follow up PR.
… introduced by mixxxdj#3956 This is a band aid. The reintroduced issue of settings path access before checking the sandbox will be fixed in a follow up PR.
… introduced by mixxxdj#3956 This is a band aid. The reintroduced issue of settings path access before checking the sandbox will be fixed in a follow up PR.
This makes sure that getSettingsPath() always return the right directory.
This is done by writing it back using args.getSettingsPathSet() when it was changed by sandboxing.
I have also moved the code into main, to make sure that CmdlineArgs::Instance()->getSettingsPath() can be used unconditionally.