Author Topic: defaults *import* versus *write*  (Read 88 times)

xairbusdriver

  • Storm
  • *****
  • Posts: 1800
    • EW7115 (E7115)
    • KTNGERMA20
    • Mid-South Weather
  • Station Details: Davis VP2 wireless w/remote wireless Anemometer Kit
defaults *import* versus *write*
« on: November 06, 2017, 05:30:09 PM »
Had a recent update to an app I use to create cron jobs. When I first opened the new version, it wanted me to re-enter my license info. No problem, although I did have to contact 'support' and ask that they send me the license code that had never been needed in the past. Came right away, of course.

Problem: After entering the correct info, the "Save License" button was still not enabled. Only alternative was to run in "Trial" mode which disabled edit/creating/saving files!

Solution: Contacted the dev and we worked through the problem with him finally sending me a plist with my license data included.

Problem: Opening the app still gave me a modal registration dialog that still had the disabled "Save..." button.

Another email from the dev provided me with a "defaults import" command. I'd never seen that before, many times I've used 'defaults write', of course. The good news is that it worked!

The other good news is that he explained why. Apparently Apple, back in 10.9, changed how the plist database (my explanation) is maintained. While the "write" command can make changes in most plists settings (usually changing a number or a string value) the "import" command seems to write to a launch(?)daemon that keeps track of and caches the plist files for apps.

The Terminal command that fixed my problem was:
Code: [Select]
defaults import com.(apps bundle name) ~/(file location)/(apps bundle name).plistNaturally, this should be done while the app is not running. This works because the daemon caches it's database and also stores it in persistent ram so it is not lost during a Restart! That speeds up things on Startup, but it also means a plist that was simply replaced is ignored!  [banghead]

I'm not saying we/you should start using "import" instead of "write". I'll let the dev make that call on his own app. And it doesn't seem to be required, usually. I am restating the need for current backups, however! As well as using the option-drag method of moving critical files like plists. I replaced that plist several times before I was able to do the "import" dance, and each time the OS dutifully re-replaced the replaced file with the one it thought should be there. [banghead] I hate it when the computer is smarter than I am... especially when it is so often! [lol]

Blicj11

  • Storm
  • *****
  • Posts: 2536
    • EW3808
    • KUTHEBER6
    • Timber Lakes Utah
  • Station Details: Davis Vantage Pro2 Plus | WeatherLinkIP™ Data Logger | iMac (late 2013), 3.5 GHz Intel Core i7, 24 GB RAM, macOS Sierra | Sharx SCNC2900 Webcam | Supportive Wife
Re: defaults *import* versus *write*
« Reply #1 on: November 06, 2017, 06:16:23 PM »
That is why Stu reminds us that when we are trying to create a new WeatherCat plist, we should delete the old one, empty the trash and reboot the machine before we re-start WeatherCat. This insures that the old plist is not restored from cache, but a new one is re-created. Same thing applies to reverting to a backup plist. Trash the old one, empty the trash, move the backup plist into place, then restart the machine.
Blick


xairbusdriver

  • Storm
  • *****
  • Posts: 1800
    • EW7115 (E7115)
    • KTNGERMA20
    • Mid-South Weather
  • Station Details: Davis VP2 wireless w/remote wireless Anemometer Kit
Re: defaults *import* versus *write*
« Reply #2 on: November 06, 2017, 06:42:17 PM »
I mentioned the often suggested Restart part. But this dev claims the daemon writes its data to persistent ram prior to the Restart. I can only assume that actually means the HD but there may be a few MB of dedicated ram that is continuously refreshed as long as the machine is plugged in.

All I know is that the old plist was simply replaced manually and the command issued. Reopening the app then used the new plist. No Restart was needed. Results are only anicdotal. I don’t like Restarting the machine running WC, so if this can work, great! Nice to have the option, at least for this app which is critical for my set up.