DT doesn't save setting between sessions #72
Comments
|
Check the permissions of "~/.config/UDP Software/Dwarf Therapist.ini", it may be owned by root (falcn's issue). |
|
@cvuchener it's |
|
I don't know MacOS well. There is some platform-specific code that request authorization. But I don't know how to make it use the privileges only for reading DF memory and not for writing files. |
|
|
|
Making the file world writable is not a good solution. It should be owned by the regular user. If you change the owner (chown), does it stay that way or DT recreates a root owned file? If it stays with the first owner, it should be possible to force the creation before the privileges are requested. But what about the other files created by DT (e.g. csv export must happen with privileges to get DF data)? I am still confused by how these authorization rights work. What does the DFInstanceOSX::authorize method exactly do? Is it displaying a dialog for requesting root permissions and then setting the effective user id to 0 if it is accepted? It may be possible to switch between root and regular user with seteuid so root is only used when accessing DF memory. |
|
Can someone try this patch? Compilation was not tested and it may be missing includes (unistd.h for the uid stuff and string.h for strerror). Run as a debug build or with -debug option, I would like to check the debug log line with the uids. |
|
Will try this now Edit: |
|
Sorry, I did notice later that getresuid was specific to linux and I forgot to fix it. Try this: https://github.com/cvuchener/Dwarf-Therapist/tree/macos-seteuid It uses only getuid, geteuid and seteuid, they should exist on any POSIX system. |
|
Not sure if it's because that branch is on 39.3.0 or if it's the permission changes but DT was unable to detect that DF 0.44.09 was running. However, settings are saved between runs properly and the ini file is owned by the user: Built with Compiler warnings: Output: Couldn't find any logs. If they should exist, let me know where to look |
Yep, it pops up a dialog requesting an admin name and password every run. I'm pretty sure apple has some sort of keychain api that may make securely storing the authorization possible as well as cleaning up permissions issues. No idea how to use it though, will do some research. Edit: I don't think keychain is what we want actually, it seems to be just for storing passwords and tokens. The api we want and I think are currently using to some extent is called Authorization Services which seems to have pretty decent documentation |
|
The warnings are known, but there is no solution yet. And I personally won't make major change to the OSX part.
That is the part I wanted to know: authorize changes the effective user id. Now you need to check if the rights can be reacquired after being dropped. There doesn't seem to be any POSIX way for getting the saved user id (since getresuid is linux only). Try reading DF memory and look for "seteuid(0) failed" errors. 3.9.1 only added new memory layouts, copy them manually or use git rebase, there should not be any conflict. |
|
rebase gave add/add conflicts on 5 files :( Edit: looks like it found it then lost it immediately? |
|
This code should supposedly get the saved uid on macOS, haven't tested though. Taken from here I will be busy pretty much all of tomorrow. Not quite sure what you meant about reading the DF memory but I should be available to test stuff again on Saturday. |
|
I added seteuid(0) in ~~~find_running_copy~~~ (set_pid now, it was missing some return paths), hopefully it will be able to find DF instance now. I also rebased on 39.3.1 (no conflict for me). |
|
Hey, got done with some stuff earlier than I thought and had a chance to run this. Output if you're interested (maybe helpful for tracking down the no equipment bug?): |
|
It should be fixed by #82, please re-open if it is still happening. |
|
According to falcn, this is not fixed for the first run. |
|
While we are here, why we save Dwarf Therapist.ini to the ~/.config/Dwarf Therapist and the rest of the app data to the ~/Library/Application Support/Dwarf Therapist? |
|
Standard location for config files is ~/Library/Preferences, but only when using native format (CFPreferences). DT stores its config in ini format for portability, and they cannot be stored at the same place. Qt decided to follow XDG specification and uses ~/.config (or XDG_CONFIG_HOME) like Linux. Reading the documentation, I guess you could say that storing ini configuration files in "Application Support" is okay, like Windows with AppData.
But DT is only using Qt's defaults. Maybe it is a Qt bug. By the way, ConfigLocation and AppConfigLocation use ~/Library/Preferences/ although the apple documentation says "You should never create files in this directory yourself. To get or set preference values, you should always use the NSUserDefaults class or an equivalent system-provided interface." |
As a long time Mac user, I'm expecting to find all application settings in ~/Library/Application Support/Appname. I'm not surprised that cross-platform apps not following guidelines and use dot folders in user home directory, happens all the time, but it just weird that DT is saving its ini files in two separate folders. I understand why it happens, but can we consolidate them in one place, preferably ~/Library/Application Support/Dwarf Therapist? |
|
The location can be overridden with QSettings::setPath, but you should consider discussing the default locations with Qt devs. Or, as a workaround, add |
Since DT don't have a shell script that I can use to control env for people who run it from a pack, I tried to be a smartass and added the following to the Info.plist as described here And it worked, now everything is neatly stored in one place. Thank you! Maybe you should push this change to the upstream? Anyway, sorry for the sidetrack, back to the topic. |
|
It is hard to control when the QSettings file is saved. If it keeps the current user after the first write, try adding Dwarf-Therapist/src/dwarftherapist.cpp Line 101 in 237f390 This should force a write early enough. Assuming it creates the file even when the QSettings object is empty. |
|
Unfortunately I can't build, I can only test.
At this step, if file stays owned by root, DT can't write to it anymore. |
|
Just wanted to add, I think it's important: If on step 2-3 file permissions are changed from 644 to 666, on step 8 file ownership gets very briefly changed to root and then returned back to user in 0.1 seconds or so. |
|
If on step 9 file gets deleted, it gets re-created on app exit with correct ownership, Nope, if file loses 666 permissions, it gets root ownership here
...and never gets returned to user, because code that does that doesn't work on root-owned files.
|
|
If I understand correctly, QSettings writes a new temporary file then rename it to replace the old one. This is done to avoid partial writes if something wrong happens when saving the file. This may be reason the permission are changed. This behavior can be changed by calling setAtomicSyncRequired. |
|
Yeah, setuid is per-process, not per-thread - see notes at http://man7.org/linux/man-pages/man2/setuid.2.html |
|
In case anyone else comes across this thread looking for how to make Dwarf Therapist save settings, the file I had to grant write access to was ~/.config/Dwarf Therapist/Dwarf Therapist.ini, not ~/.config/UDP Software/Dwarf Therapist.ini. Hopefully this helps someone avoid an hour and a half of messing around. :-D |
|
As part of #167, I made some changes that may help with this issue. Logs were also created as root. With 73b5c8f DT will drop root privileges earlier (as soon as the QApplication object is created, for some reason I cannot do it in main). I still don't control when settings are saved, but DT will spend less time as root, so it should be rarer. |
|
Hi! running the latest DT, still doesn't save between sessions and is now crashing at every startups. sometimes opens (mac os) and crashes every time I am trying to quit it. |
Any crash log?
Config file is in |
|
thanks for the quick answer @cvuchener crash log on open (right after I enter my password): https://pastebin.com/qZtnhraf Also deleted all files in folders you listed, the crash logs are from a clean new install Still not loading my settings when I managed to start DT Attached DT logs from the log folder (there are 4 logs in the folder) |
|
I can reproduce the crash with the release build, but not when I recompile myself. I found something wrong with RoleModel, but I am not sure it is the cause of the crash. I cannot manage to use valgrind on the macOS version I have access too, so it is hard to debug. |
|
Does this version solves the crash for you? |
|
This version looks like it is not crashing! (just once in my tests, but that one crash can be discarded). On the other hand it is not saving the settings yet |
|
I guess it is the usual issue about the ownership of ~/.config/Dwarf Therapist/Dwarf Therapist.ini. Since I don't think I can really fix this one, let's try to make the workaround automatic. Try this release. It should try to chown to config file when quitting (assuming it does not crash before). |
|
This release crashes upon exit: https://pastebin.com/pcJUeXBN and therefore doesn't save |
|
This one should work better. |
|
sadly crashes right after entering the password https://pastebin.com/paUu0dqf |
|
Sorry I cannot reproduce this. From the backtrace it is either a Qt bug, or a memory corruption happening earlier that I cannot find by just looking at the crash log. |
|
ouch, anything I can do to help? |
|
I am not an expert on macOS debugging. Valgrind can often give good information on memory corruption, but it is not available for recent versions of macOS. Maybe there is another tool that can help, but I don't know it. |
|
Currently to use the Lazy Mac Pack requires users to run a shell script to make PyLNP, DFHack, nearly every utility, and some libraries work properly. I'm dealing with the settings-not-saving issue by having the shell script "touch" the settings file. In this way before Dwarf Therapist is run, the settings file is already created with permissions that allow settings to be saved. Probably doesn't help, but just in case: Upside is that it doesn't require admin password for sudo. Downside is that it doesn't fix the problem if the settings file already exists with bad permissions. Imo, the "touch" command should create the parent directories if they don't already exist, but unfortunately, it doesn't. |
|
|
That was what I attempted to do in e1fcd55 but it broke DT for unknown reasons (#177) so it was reverted (5140ef5).
There is a trick I know on Linux (but I don't know if it is portable) for changing ownership of a file you don't own but can read in a directory you own. You can delete files in directories you own, so make a copy then replace the original. |
|
Instead of dropping permissions as e1fcd55 does, I was suggesting creating the file before escalating to root (e.g. in |
|
Whoever wonders about a fix, right now it's |
|
I see you are still messing with ~/.config/
|
|
@falcn oh, I have missed that part. Thanks for point out! |
|
ok, I just read all of this and I cant understand what I am supposed to do to fix this issue could someone explain. |
|
Try changing the permissions (
|
Macos, v39.3.0Not sure if its a bug or feature but every time I run the program, it set all setting to default. For example I can check option "Dont display children", restart Therapist, and it will be unchecked again.
The text was updated successfully, but these errors were encountered: