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 (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
