Today I learned that the defaults(1) command on macOS can break otherwise-parsable plist files.
I found this when trying to change selectedThrottleIndex in the Arq config (~/Library/Arq/config/app_config.plist) to adjust a bandwidth usage setting. I didn’t have access to the GUI, wanted to change things from CLI, and whoops! After changing this things broke.
Consider this… First I read out the setting with defaults read ~/Library/Arq/config/app_config.plist selectedThrottleIndex, then set it with defaults write ~/Library/Arq/config/app_config.plist selectedThrottleIndex 2, then read it again to verify the change. All looked good, so I figured I was done and I let things bake.
Upon getting physical access to the machine and launching the GUI, I found that Arq was no longer activated, needed my license info again, and then (uggh!) had lost my configuration. This was fixed by first restoring the whole of ~/Library/Arq from Time Machine, launching Arq, browsing to the backup destination, and clearing it’s cache. After rescanning the destination all was good.
So, why did it happen? Well, it turns out that Arq uses a headerless XML-ish text file with the suffix .plist. Even though it’s not in the same format as plutil(1) outputs, defaults(1) will still read it and modify it… But the resulting file is a plist binary! It seems that Arq only likes to parse its format (note: I did not exhaustively test this — plutil(1)‘s xml1 format may work), so upon seeing the binary version it the program presumed no config and started over. Whoops! Interestingly, the defaults(1), plutil(1), and pl(1) commands will all happily parse the Arq format file.
Note that after launching Arq with the broken config and re-adding the license, restoring just the app_config.plist file didn’t make things better, which is why I jumped right to restoring the whole ~/Library/Arq directory. There must be some config caching somewhere or so…