A weird bug to write plist to a file

Recently, I encountered a weird bug that I could not have a clue about. I have an API to save the configuration settings to a plastic, which is located at "/Library/Preferencs/Bitglass". The writer is a daemon and the function looks as follows. The weird thing I found recently was that the function could not save the IPC server port value when the daemon was installed by another installer daemon. But it can save other plastic values without any problems. When the list was not saved to a file, there is not any error messages. The following function is called by two daemons to save different settings into a plastic file. Is there anyone who has any clue why it failed to save the plist to a file when the daemon is installed and launched by another daemon?

  • (BOOL)setValue:(const char *)key value:(const char *)value {

std::lock_guard<std::mutex> lock(plist_mutex); NSString *nskey = [NSString stringWithUTF8String:key]; NSString *nsval = [NSString stringWithUTF8String:value]; @try { [data setObject:nsval forKey:nskey]; if (![data writeToFile:plistPath atomically:YES]) { BGLOG(LOG_ERROR, "Failed to write" << key << "=" << value); return FALSE; } return TRUE; } @catch (NSException *e) { BGLOG(LOG_ERROR, "Caught exception:" << [e.name UTF8String] << " reason:" << [e.reason UTF8String]); return FALSE; }

Replies

When things fail, does -writeToFile:atomically: return false? If so, what error do you get back?

The weird thing I found recently was that the function could not save the IPC server port value

What sort of IPC are you using here? Unix domain sockets?

ps If you’re going to post code, please use a code block. Otherwise it comes out unreadable. See Quinn’s Top Ten DevForums Tips for this and lots of other tips.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"