Re: SCPreferencesLock issue?
Re: SCPreferencesLock issue?
- Subject: Re: SCPreferencesLock issue?
- From: Jeremy Matthews <email@hidden>
- Date: Fri, 17 Sep 2010 05:25:04 -0400
Nevermind; figured it out.
I DID manage to copy and paste sections in the wrong order; hence some of the confusion there...and forget the comment blocks I had around certain twice-delivered functions.
Thanks,
j
On Sep 17, 2010, at 4:05 AM, Ken Thomases wrote:
> On Sep 17, 2010, at 2:43 AM, Jeremy Matthews wrote:
>
>> For some reason, I can't seem to get a lock....was wondering if anyone else has been here before:
>
> I haven't dealt with this API before, but the below code is a mess. You also don't explain what you mean by "I can't seem to get a lock". The logging statements in the code are almost but not quite sufficient explanation. What did you try? What results did you expect? What actual results did you encounter?
>
>>
>> AuthorizationRef auth = nil;
>> OSStatus authErr = noErr;
>>
>> AuthorizationFlags rootFlags = kAuthorizationFlagDefaults
>> | kAuthorizationFlagExtendRights
>> | kAuthorizationFlagInteractionAllowed
>> | kAuthorizationFlagPreAuthorize;
>>
>> authErr = AuthorizationCreate(nil, kAuthorizationEmptyEnvironment, rootFlags, &auth);
>
> No evidence that you're checking if this succeeded.
>
>>
>> SCPreferencesRef prefs;
>> //SCPreferencesRef prefsWithAuth;
>>
>> CFStringRef appName = CFSTR("com.test.testapp");
>> CFStringRef computerName = CFSTR("macbookpro2");
>>
>> SCPreferencesLock(prefs, NO);
>
> Here you have passed an uninitialized 'prefs' variable into SCPreferencesLock(). If you aren't crashing here, it's pure luck. Even if you don't crash, passing the garbage value in may have thoroughly corrupted the framework internals, making the rest of the test invalid.
>
>>
>> if ( geteuid() != 0 )
>> {
>> prefs = SCPreferencesCreateWithAuthorization(NULL, appName, NULL, auth);
>> }
>> else
>> {
>> prefs = SCPreferencesCreate(NULL, appName, NULL);
>> }
>
> Which branch of the above did you test?
>
>>
>> if (prefs == nil)
>> NSLog(@"InterfaceConfig failure: SCPreferencesCreate failed");
>>
>> SCPreferencesLock(prefs, NO);
>>
>> if (prefs && SCPreferencesLock(prefs, TRUE))
>
> You have attempted to obtain the lock twice. Not all locks are "recursive". Attempting to obtain a lock that you already hold may deadlock or the API may detect the deadlock and return failure. Since you are only using the second attempt to determine if the lock was obtained, it's not informative.
>
>> {
>> //We got a write lock, that means we can do whatever
>> //we want to /Library/Preferences/SystemConfiguration/preferences.plist
>> NSLog(@"LOCK OBTAINED");
>> } else {
>> NSLog(@"LOCK NOT OBTAINED");
>> }
>>
>> SCPreferencesSetComputerName(prefs, computerName, kCFStringEncodingUTF8);
>>
>> SCPreferencesCommitChanges(prefs);
>>
>> if(!SCPreferencesCommitChanges(prefs))
>
> According to the docs, SCPreferencesCommitChanges() implicitly obtains the lock, which raises the question of whether it's recursive again. Also, you commit the change once without checking the result and then commit them again. If the second is failing, it could be because the first succeeded.
>
>> {
>> NSLog(@"can't commit changes");
>> }
>>
>> SCPreferencesApplyChanges(prefs);
>> if(!SCPreferencesApplyChanges(prefs))
>
> Ditto.
>
>> {
>> NSLog(@"can't apply changes");
>> }
>>
>> SCPreferencesUnlock(prefs);
>> CFRelease(prefs);
>
> Regards,
> Ken
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden