You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(Here’s my known-good prefs plist with what I consider the optimal performance-monitoring column set:ru.domo.CocoaTop-badger200knowngood.plist.txt - simply rename to ru.domo.CocoaTop.plist, GitHub wouldn’t accept it until I attached as TXT)
On both my devices when I updated to 12.4, CocoaTop would not save my custom column preferences. This was extremely annoying until I finally discovered a fix.
I noticed ru.domo.CocoaTop.plist was in
/var/root/Library/Preferences
But it seemed like similar apps were far more likely to have such a prefs file located in
/var/mobile/Library/Preferences
I made a workaround by:
creating a known-good custom columns set
Verifying the .plist modified time was current to confirm my changes were saved (for the moment)
Copying that .plist from root Preferences to mobile Preferences as mentioned above.
I don't know how, why, or if this is what fixed it but it certainly seems to be. I remember checking permissions (bc it was almost as if CocoaTop was perhaps unable to save my changes to disk, which would explain why it always restarted with default column again.)
The odd thing is, my
/var/root/Library/Preferences/ru.domo.CocoaTop.plist gets updated to current time basically every time I use the app.
HOWEVER, my workaround copy at /var/mobile/Library/Preferences/ru.domo.CocoaTop.plist oddly DOES get updated - but only once every 7-10 days! I have no clue how to explain this behavior.
The text was updated successfully, but these errors were encountered:
badger200
changed the title
Custom Columns fail to save on iOS 12.4
Custom Columns fail to save on iOS 12.4 (w/workaround/fix)
Mar 1, 2020
badger200
changed the title
Custom Columns fail to save on iOS 12.4 (w/workaround/fix)
Custom Columns fail to save on iOS 12.4 (workaround/fix)
Mar 1, 2020
If CocoaTop is being run as root (as all the older versions were), then the config is saved in /var/root/Library/Preferences. otherwise it's created in /var/mobile/Library/Preferences. Check owner/group and access rights of /var/mobile/Library/Preferences/ru.domo.CocoaTop.plist, the owner should be mobile.
If you want CocoaTop to be run as root, you should: # chown root.wheel /Applications/CocoaTop.app/CocoaTop # chmod +s /Applications/CocoaTop.app/CocoaTop
@D0m0 I found my /Applications/CocoaTop.app/CocoaTop was already root:wheel 755. But did not have the +s (6755).
However I didn’t see any difference when I tested it with +s. The only thing I could think of testing was Ports (which always freezes, see my large comment made moments ago on the big iOS 13 commit). And it still freezes even with +s. So I just reverted (-s).
(Here’s my known-good prefs plist with what I consider the optimal performance-monitoring column set: ru.domo.CocoaTop-badger200knowngood.plist.txt - simply rename to ru.domo.CocoaTop.plist, GitHub wouldn’t accept it until I attached as TXT)
On both my devices when I updated to 12.4, CocoaTop would not save my custom column preferences. This was extremely annoying until I finally discovered a fix.
I noticed ru.domo.CocoaTop.plist was in
/var/root/Library/Preferences
But it seemed like similar apps were far more likely to have such a prefs file located in
/var/mobile/Library/Preferences
I made a workaround by:
I don't know how, why, or if this is what fixed it but it certainly seems to be. I remember checking permissions (bc it was almost as if CocoaTop was perhaps unable to save my changes to disk, which would explain why it always restarted with default column again.)
The odd thing is, my
/var/root/Library/Preferences/ru.domo.CocoaTop.plist gets updated to current time basically every time I use the app.
HOWEVER, my workaround copy at /var/mobile/Library/Preferences/ru.domo.CocoaTop.plist oddly DOES get updated - but only once every 7-10 days! I have no clue how to explain this behavior.
The text was updated successfully, but these errors were encountered: