CallDirectory Handler extension error while using Realm - ios

I'm using Callkit extension to identify the numbers. All my contacts (around 30k+) are stored in Realm.
I have stored the Realm file in AppGroup which can be shared between my app and its extensions.
I get the error when I try to reload the extension.
Error Domain=com.apple.CallKit.error.calldirectorymanager Code=7
"(null)"
When this error occurred , the setting for Call Blocking & Identification for my app shows a spinner (while other apps show the switch to toggle)
- (void)applicationDidBecomeActive:(UIApplication *)application
{
[[CXCallDirectoryManager sharedInstance] reloadExtensionWithIdentifier:#"com.j2x.handheldcontact.CallerID" completionHandler:^(NSError *error){
if(error) {
NSLog(#"CallerID - refresh failed. error is %#",[error description]);
}
}];
}
I see that the error happens only when I try to use access the Realm in the app group directory.
In my extension subclass:
- (void)beginRequestWithExtensionContext:(CXCallDirectoryExtensionContext *)context
{
context.delegate = self;
NSString *appGroupId = #"group.com.j2x.handheldcontact.CallerID";
NSURL *appGroupDirectoryPath = [[NSFileManager defaultManager] containerURLForSecurityApplicationGroupIdentifier:appGroupId];
NSURL *dataBaseURL = [appGroupDirectoryPath URLByAppendingPathComponent:#"default.realm"];
[[[RLMRealm defaultRealm]configuration]setFileURL:dataBaseURL];
RLMResults *temp = [self getContactArray]; //This gives the callKit error
RLMResults *temp ; //This doesn't give any error
[context completeRequestWithCompletionHandler:nil];
}
-(RLMResults *)getContactArray{
RLMResults *res = [[RealmContact allObjects]objectsWithPredicate:[NSPredicate predicateWithFormat:#"phone <> nil or homePhone <> nil or mobilePhone <> nil or altPhone <> nil or fax <> nil"]];
return res;
}
Why does accessing the Realm data gives the error ? The predicate format does look ok to me.
With some research I found the following code:
public enum Code : Int {
public typealias _ErrorType = CXErrorCodeCallDirectoryManagerError
case unknown
case noExtensionFound
case loadingInterrupted
case entriesOutOfOrder
case duplicateEntries
case maximumEntriesExceeded
case extensionDisabled
#available(iOS 10.3, *)
case currentlyLoading
#available(iOS 11.0, *)
case unexpectedIncrementalRemoval
}
In my case , the error says case currentlyLoading (code 7). I also tried this on realm with only 250 contacts . But I got the same error.
Edit:
If I hardcode the contact, it works fine. But if I bring Realm into scene, it fails.
CXCallDirectoryPhoneNumber phoneNumber = strtoull([#"14xxxxxx86" UTF8String], NULL, 0);
if (phoneNumber > 0) {
[context addIdentificationEntryWithNextSequentialPhoneNumber:phoneNumber label:#"Test Test"];
}
Workaround:
For now, I'm storing all my data into a file and saving that file in the app group.
NSString *appGroupId = #"group.xxx.CallerID";
NSURL *appGroupDirectoryPath = [[NSFileManager defaultManager] containerURLForSecurityApplicationGroupIdentifier:appGroupId];
NSURL *appFile = [appGroupDirectoryPath URLByAppendingPathComponent:#"contacts.txt"];
BOOL exists = [[NSFileManager defaultManager] fileExistsAtPath:[appFile path]];
if(exists) {
[[NSFileManager defaultManager]removeItemAtPath:[appFile path] error:nil];
}
[NSKeyedArchiver archiveRootObject:uniqueCallDirectory toFile:[appFile path]];
and accessing this array in the callID extension subclass.

The list you provide to addIdentificationEntryWithNextSequentialPhoneNumber must be ordered by ascending phone Number. Retrieve the list from realm in ascending order. (else it will break and keep the loading icon when you activate the extension)

Related

How do I get around NSCocoaErrorDomain:257 when pulling a file from the Files app?

I'm trying to access a file to pull a copy into my app so that users can associate it with relevant information. It used to work just fine up until recently, and now I suddenly am getting the following message:
Failed to read file, error Error Domain=NSCocoaErrorDomain Code=257 "The file “[File name]” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=/private/var/mobile/Library/Mobile Documents/com~apple~CloudDocs/[File name], NSUnderlyingError=0x281b88690 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}
This is the code that's throwing the error:
//AppDelegate.m
-(BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options
{
if (![url.pathExtension isEqualToString:#"pdf"] && ![url.pathExtension isEqualToString:#"png"] && ![url.pathExtension isEqualToString:#"jpg"] && ![url.pathExtension isEqualToString:#"jpeg"]){
return false;
}
NSError* error = nil;
NSString *path = [url path];
NSData *data = [NSData dataWithContentsOfFile:path options: 0 error: &error];
if(data == nil) {
NSLog(#"Failed to read file, error %#", error);
}
//Do stuff with the file
return true;
}
I did update to xcode 11 and iOS 13, so there may have been a change there that I wasn't aware of.
It turns out there's a "using" function that tells the app its accessing files outside of it's sandbox. The methods startAccessingSecurityScopedResource and stopAccessingSecurityScopedResource on NSURL need to be wrapped around the code using the url, like so:
BOOL isAcccessing = [url startAccessingSecurityScopedResource];
NSError* error = nil;
NSString *path = [url path];
NSData *data = [NSData dataWithContentsOfFile:path options: 0 error: &error];
if(data == nil) {
NSLog(#"Failed to read file, error %#", error);
}
if (isAccessing) {
[url stopAccessingSecurityScopedResource];
}
I'm not sure if there's anything specific to iOS 13 that requires this when it didn't previously, but that is the only real change between it working and not working.
Jordan has a great answer! Here's the version translated to Swift
let isAccessing = url.startAccessingSecurityScopedResource()
// Here you're processing your url
if isAccessing {
url.stopAccessingSecurityScopedResource()
}
As I encountered this myself and the comment to Jordan's answer confirmed this happens only on the real device. Simulator has no such an issue

iOS Core Data saveContext method is unsuccessful due to NSSQLiteErrorDomain = 1032

Some background for this issue, I'm trying to include what I think may be relevant to help understand the context.
I am currently adding an linked library which used Core Data to save some user information and a feature which adds an Entity to the pre-existing Core Data model already in the app. Each managedObjectContext has its own instance when created (verified) as well as its own PSC and MOM and neither interact with the other's entities(thus seem to be independent).
The entirety of the following code, errors, and (I believe issue) is in the Main Target of the app. (Hopefully) not the newly added linked library.
The saveContext method is:
- (void)saveContext {
dispatch_async(dispatch_get_main_queue(), ^{
NSError *error = nil;
// Register
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(myManagedObjectContextDidSaveNotificationHandler:) name:NSManagedObjectContextDidSaveNotification object:self.managedObjectContext];
if (self.managedObjectContext != nil) {
if ([self.managedObjectContext hasChanges]) {
BOOL success = [self.managedObjectContext save:&error];
if (!success) {
[Error showErrorByAppendingString:NSLocalizedString(#"UnableToSaveChanges", nil) withError:error];
} else {
//
}
}
}
// Unregister
[[NSNotificationCenter defaultCenter] removeObserver:self name:NSManagedObjectContextDidSaveNotification object:self.managedObjectContext];
});
}
When called, error = nil, success = NO and by forcing the compiler past the exception I get the following:
CoreData: error: exception during obtainPermenantIDsForObjects: Updating max pk failed: attempt to write a readonly database with userInfo of { NSSQLiteErrorDomain = 1032;
}
I have googled, "NSSQLiteErrorDomain = 1032", "obtainPermenantIDsForObjects", and "CoreData readonly database". It does appear that the key primary key for each object is the same, but I am setting that value, I believe sqlite is. I have not found any solutions to help with this. I do have the argument passed on launch, "Concurrency Debug 1" set to on.
I have not implemented obtainPermenantIDsForObjects and I've searched the whole project and cant find its implementation so I think CoreData is using this.
The saveContext method is called on the main queue because thats how my predecessors rolled out the code and I don't have time at the moment to deal with it.
The method calling saveContext (from a background thread):
- (NSMutableArray *)convertRawStepDataTo:(NSMutableArray*)steps
withDates:(NSMutableArray*)dates
inManagedObjectContext:(NSManagedObjectContext*)theMOC {
NSMutableArray *theStepsArray = [[NSMutableArray alloc] init];
// prepare values for chart
AppDelegate *delegate = (AppDelegate *)[UIApplication sharedApplication].delegate;
StepSelector *theSelector = [[StepSelector alloc] init];
NSString* apiSelectionForStep = [theSelector getCurrentSelectionString];
for (int iter = 0; iter < steps.count; iter++) {
NSNumber *currStepValue = [steps objectAtIndex:iter];
// NSNumber *stepCountforIter = [NSNumber numberWithLong:[[steps objectAtIndex:iter] longValue]];
NSNumber* dateForIter = [NSNumber numberWithLong:[[dates objectAtIndex:iter] longLongValue]];
Step *step = [delegate addStepObjectToPersistentStorewithAPI:apiSelectionForStep
andStep:stepCountforIter
andDate:dateForIter
forMOC:theMOC];
[theStepsArray addObject:step];
if (VERBOSE) {
NSLog(#"This is step number %d, with object ID: %#", count, [theMOC objectWithID:step.objectID]);
count++;
}
}
[delegate saveContext];
return theStepsArray;
}
Thats all I can think that might help. The source for the MOC in the main target is the appDelegate which is where all the core data code was written initially.
EDIT Here is the requested PSC code. The store is located in the documents directory. I discovered that these objects are being saved to the Persistent Store.. but the error is still occurs. Se below for PSC code:
- (NSPersistentStoreCoordinator *)persistentStoreCoordinator {
if (persistentStoreCoordinator != nil) {
return persistentStoreCoordinator;
}
NSURL *storeUrl = [self getStoreURL];
// Rollback journalling mode...
NSDictionary *options = [NSDictionary dictionaryWithObjectsAndKeys:
[NSNumber numberWithBool:YES], NSMigratePersistentStoresAutomaticallyOption,
[NSNumber numberWithBool:YES],NSInferMappingModelAutomaticallyOption,
NSFileProtectionComplete, NSFileProtectionKey,
#{#"journal_mode": #"TRUNCATE"}, NSSQLitePragmasOption, nil];
persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel: [self managedObjectModel]];
NSError *error = nil;
self.persistentStore = [persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeUrl options:options error:&error];
if (!self.persistentStore) {
NSLog(#"Error: %#",error);
[Error showErrorByAppendingString:NSLocalizedString(#"UnableToFindDatabaseFile", nil) withError:error];
}
return persistentStoreCoordinator;
}
-(NSURL *)getStoreURL {
NSString *storePath = [[self applicationDocumentsDirectory] stringByAppendingPathComponent: kSQLFILENAME];
/*
Set up the store.
For the sake of illustration, provide a pre-populated default store.
*/
NSFileManager *fileManager = [NSFileManager defaultManager];
// If the expected store doesn't exist, copy the default store.
if (![fileManager fileExistsAtPath:storePath]) {
NSString *defaultStorePath = [[NSBundle mainBundle] pathForResource:SQLFILEPATHRESOURCE ofType:#"sqlite"];
if (defaultStorePath) {
[fileManager copyItemAtPath:defaultStorePath toPath:storePath error:NULL];
}
}
NSURL *storeUrl = [NSURL fileURLWithPath:storePath];
return storeUrl;
}
The NSSQLiteErrorDomain key means that this error came from SQLite, and that Core Data is passing it back to you. SQLite defines error 1032 as follows:
The SQLITE_READONLY_DBMOVED error code is an extended error code for SQLITE_READONLY. The SQLITE_READONLY_DBMOVED error code indicates that a database cannot be modified because the database file has been moved since it was opened, and so any attempt to modify the database might result in database corruption if the processes crashes because the rollback journal would not be correctly named.
...which appears to mean that SQLite is making the persistent store file read only because something has happened to it since it was opened, and SQLite is trying to prevent data corruption.
I don't see anything in the code you've posted that is obviously at fault, at least as far as the error code description goes. So I wonder, are you doing anything anywhere else that would directly affect the persistent store file (i.e. touching the file in any way at all instead of going through Core Data fetch/save calls)?
The mention of the rollback journal in the error code description makes me wonder if setting journal_mode to TRUNCATE is related. If it were me, I'd remove that (I don't know what it's intended to accomplish here) or set it to DELETE. At least for testing purposes, anyway, in the hope of understanding the problem better.

Unable to remove SQLite Database file

I am new to Xcode and ios. I am using Xcode 7.3 version and swift2.2
I have removed a per-populated SQlite Db from my project. Later, I used Add file menu in Xcode to add the same name SQLite Db with only modified the content of the field. Example , fieldname :addr , the content :123, 5th ave , now the same filedname :addr ,the content :12, Broadway
After added the modified content SQLite DB, the code STILL using the old content that is 123,5th ave!
let querySQL = "select Sid, location, Addr from tblPlaces where Sid =" + myId
let result: FMResultSet? = MyDB.executeQuery(querySQL, withArgumentsinArray:nil)
if result?.next() == true {
let strAddr = results!stringForColumn("Addr")
}else {
}
I have created a class to handle the creation of SQLite DB in AppDelegate:
Util.copyFile("SqliteDB filename")
here the code:
class func copyFile(fileName: NSString) {
var dbPath: NSString = getPath(fileName)
var fileManager = NSFileManager.defaultManager()
if !fileManager.fileExistsAtPath(dbPath) {
let documentsURL = NSBundle.mainBundle().resourceURL
let fromPath = documentsURL!.URLByAppendingPathComponent(filename as string)
var error : NSError?
do {
try filemanager.CopyItemAtPath(fromPath.path!, toPath: dbPath)
}catch let error1 as NSError {
error = error1
}
}
// GetPath of the SQLite file
class func getPath(filename : String) -> string {
let documentDirectory = try! NSFileManager.defaultManager().URLForDirectory(.DocumentDirectory,inDomain:
UserDomainMask, appropriateURLURL:nil, create: true)
return documentDirectory.URLbyAppendingPathComponent(filename).path!
}
What this happened? How to do the right way?
If I remove the SQlite Db file say MyDB.sqlite, and later I add in the same name Db file with content modified, I should get the new content. But this is not the case.
You are putting your file in the application bundle, i.e., to be distributed with your app. That file is read only. To update the file (including scheme restructuring) you would need to copy the the file to your documents folder, and update it there. Otherwise, your update will fail, leaving you with the same file as before.
I think this is what is happening.
For distribution it is also necessary that any such file be flagged NOT to backup to icloud or the app is rejected.
I use the following method (sorry, obj c) to copy the file from the bundle to the documents directory (sorry this code is sloppy but it may convey the basic idea).
+ (void)copyBundleFileToStoresDirectory:(NSString *)filename
{
NSError *error;
NSURL *fileURL = [NSURL fileURLWithPath: [[NSBundle mainBundle] pathForResource:filename ofType:nil]];
NSURL *pathURL = [SVOFileSystemMethods documentsSubdirectory:#"Stores" skipBackup:YES];
if (fileURL)
{
if([[NSFileManager defaultManager] copyItemAtURL:fileURL toURL:pathURL error:&error])
{
// NSLog(#"File successfully copied");
}
else
{
[[[UIAlertView alloc]initWithTitle:NSLocalizedString(#"error", nil) message: NSLocalizedString(#"Failed to copy database from bundle.", nil)
delegate:nil cancelButtonTitle:NSLocalizedString(#"OK", nil) otherButtonTitles:nil] show];
NSLog(#"Error description-%# \n", [error localizedDescription]);
NSLog(#"Error reason-%#", [error localizedFailureReason]);
}
}
}
// // flags URL to exclude from backup //
+ (BOOL) addSkipBackupAttributeToItemAtURL:(NSURL *)URL {
NSError *error = nil;
BOOL success = [URL setResourceValue: [NSNumber numberWithBool: YES]
forKey: NSURLIsExcludedFromBackupKey error: &error];
if(!success)
{
NSLog(#"Error excluding %# from backup %#", [URL lastPathComponent], error);
}
return success; }

Clean (remove) a database in MagicalRecord

I have an app that is using MagicalRecord for its Core Data handling and this works nice. However I have different users that can login in the app and when another user logs in, the core data database must be emptied so that the different user can have his own data. The database can be emptied completely as the data is also stored on a webservice and therefore can always be synced again after logging in again the first user.
So far I cannot seem to find a helper method (that works) for this purpose. I have tried
[MagicalRecord cleanUp];
whenever the user is logging out, but this does not do the trick.
This is how I did it. It is essential to have this line: [MagicalRecord cleanup]. Without it, [self setupDB] won't work.
UPDATE: Deletes the -wal and -shm files. #thattyson pointed out an issue in iOS 9. Also, see the answer of #onmyway133.
- (void)setupDB
{
[MagicalRecord setupCoreDataStackWithAutoMigratingSqliteStoreNamed:[self dbStore]];
}
- (NSString *)dbStore
{
NSString *bundleID = (NSString *)[[NSBundle mainBundle] objectForInfoDictionaryKey:(NSString *)kCFBundleIdentifierKey];
return [NSString stringWithFormat:#"%#.sqlite", bundleID];
}
- (void)cleanAndResetupDB
{
NSString *dbStore = [self dbStore];
NSError *error1 = nil;
NSError *error2 = nil;
NSError *error3 = nil;
NSURL *storeURL = [NSPersistentStore MR_urlForStoreName:dbStore];
NSURL *walURL = [[storeURL URLByDeletingPathExtension] URLByAppendingPathExtension:#"sqlite-wal"];
NSURL *shmURL = [[storeURL URLByDeletingPathExtension] URLByAppendingPathExtension:#"sqlite-shm"];
[MagicalRecord cleanUp];
if([[NSFileManager defaultManager] removeItemAtURL:storeURL error:&error1] && [[NSFileManager defaultManager] removeItemAtURL:walURL error:&error2] && [[NSFileManager defaultManager] removeItemAtURL:shmURL error:&error3]){
[self setupDB];
}
else{
NSLog(#"An error has occurred while deleting %#", dbStore);
NSLog(#"Error1 description: %#", error1.description);
NSLog(#"Error2 description: %#", error2.description);
NSLog(#"Error3 description: %#", error3.description);
}
}
Here's the Swift version:
func setupDB() {
MagicalRecord.setupCoreDataStackWithAutoMigratingSqliteStoreNamed(self.dbStore())
}
func dbStore() -> String {
return "\(self.bundleID()).sqlite"
}
func bundleID() -> String {
return NSBundle.mainBundle().bundleIdentifier!
}
func cleanAndResetupDB() {
let dbStore = self.dbStore()
let url = NSPersistentStore.MR_urlForStoreName(dbStore)
let walURL = url.URLByDeletingPathExtension?.URLByAppendingPathExtension("sqlite-wal")
let shmURL = url.URLByDeletingPathExtension?.URLByAppendingPathExtension("sqlite-shm")
var removeError: NSError?
MagicalRecord.cleanUp()
//Swift 1
//let deleteSuccess = NSFileManager.defaultManager().removeItemAtURL(url, error: &removeError)
//Swift 2
let deleteSuccess: Bool
do {
try NSFileManager.defaultManager().removeItemAtURL(url)
try NSFileManager.defaultManager().removeItemAtURL(walURL!)
try NSFileManager.defaultManager().removeItemAtURL(shmURL!)
deleteSuccess = true
} catch let error as NSError {
removeError = error
deleteSuccess = false
}
if deleteSuccess {
self.setupDB()
} else {
println("An error has occured while deleting \(dbStore)")
println("Error description: \(removeError?.description)")
}
}
To expand on #yoninja 's answer, this will make reset CoreData stack explicitly, plus dealing with wal and shm files
- (void)setupDB
{
[MagicalRecord setDefaultModelNamed:#"Model.momd"];
[MagicalRecord setupCoreDataStack];
}
- (void)cleanAndResetupDB
{
[MagicalRecord cleanUp];
NSString *dbStore = [MagicalRecord defaultStoreName];
NSURL *storeURL = [NSPersistentStore MR_urlForStoreName:dbStore];
NSURL *walURL = [[storeURL URLByDeletingPathExtension] URLByAppendingPathExtension:#"sqlite-wal"];
NSURL *shmURL = [[storeURL URLByDeletingPathExtension] URLByAppendingPathExtension:#"sqlite-shm"];
NSError *error = nil;
BOOL result = YES;
for (NSURL *url in #[storeURL, walURL, shmURL]) {
if ([[NSFileManager defaultManager] fileExistsAtPath:url.path]) {
result = [[NSFileManager defaultManager] removeItemAtURL:url error:&error];
}
}
if (result) {
[self setupDB];
} else {
NSLog(#"An error has occurred while deleting %# error %#", dbStore, error);
}
}
MagicalRecord does not provide this functionality for you. The cleanUp method is provided for you to reinitialize your CoreData stack in memory and cleaning up any contexts, queues and other related objects. However, it is not that difficult to do yourself given that MagicalRecord does provide a handy method to get the path for your library.
Check out the -[NSPersistentStore MR_urlForStoreName:] method. This will give you the file url for your store. You can then delete it with an NSFileManager instance. Be careful to do this before you set up the Core Data stack or you'll crash when you save because you'd have yanked out the store from under a properly initialized stack.
The following will completely delete the MagicalRecord CoreData sqlite files, as well as the -wal and -shm files. MagicalRecord puts them all in the Library folder; this will simply remove all files from the folder. This will not work if you have other data you need to persist in the Library folder, I did not:
- (void)resetCoreDataDB
{
[MagicalRecord cleanUp];
[self deleteFilesInLibrary];
[MagicalRecord setupCoreDataStackWithAutoMigratingSqliteStoreNamed:#"YourDBName.sqlite"];
}
- (void)deleteFilesInLibraryDirectory
{
NSString* folderPath = [NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES) objectAtIndex:0];
NSError *error = nil;
for (NSString *file in [[NSFileManager defaultManager] contentsOfDirectoryAtPath:folderPath error:&error])
{
[[NSFileManager defaultManager] removeItemAtPath:[folderPath stringByAppendingPathComponent:file] error:&error];
if(error)
{
NSLog(#"Delete error: %#", error.description);
}
}
}
If you are using the iOS Simulator and deleted the database file, you may probably notice that the data is still there. However, if tested on an actual device (which should be), the file is deleted and the context is reset as should be.
[MagicalRecord cleanUp];
// delete database file
NSError *error;
NSURL *fileURL = [NSPersistentStore MR_urlForStoreName:#"db.sqlite"];
[[NSFileManager defaultManager] removeItemAtURL:fileURL error:&error];
if(error) {
// Hanldle error
}
// reset setup.
[MagicalRecord setupCoreDataStackWithAutoMigratingSqliteStoreNamed:#"db.sqlite"];
A bit rewritten answer of #yoninja for Swift 4:
private var dbStore : String? {
get {
if let bundleId = Bundle.main.bundleIdentifier {
return bundleId + ".sqlite"
}
return MagicalRecord.defaultStoreName()
}
}
func setupCoreDataStack() {
MagicalRecord.setupCoreDataStack(withAutoMigratingSqliteStoreNamed: self.dbStore)
}
func cleanUp() {
MagicalRecord.cleanUp()
var removeError: NSError?
let deleteSuccess: Bool
do {
guard let url = NSPersistentStore.mr_url(forStoreName: self.dbStore) else {
return
}
let walUrl = url.deletingPathExtension().appendingPathExtension("sqlite-wal")
let shmUrl = url.deletingPathExtension().appendingPathExtension("sqlite-shm")
try FileManager.default.removeItem(at: url)
try FileManager.default.removeItem(at: walUrl)
try FileManager.default.removeItem(at: shmUrl)
deleteSuccess = true
} catch let error as NSError {
removeError = error
deleteSuccess = false
}
if deleteSuccess {
self.setupCoreDataStack()
} else {
print("An error has occured while deleting \(self.dbStore)")
print("Error description: \(removeError.debugDescription)")
}
}

Error (LibrarianErrorDomain error 2) when turning iCloud sync off for a UIDocument file with setUbiquitous

I am running into an error when I try to turn iCloud sync off for a UIDocument file. Wondering if anyone else has run into this. Here's the scenario:
I create a UIDocument file locally in the app sandbox and then make the following call to begin syncing the file with iCloud:
[[NSFileManager defaultManager] setUbiquitous:YES itemAtURL:localPathURL destinationURL:cloudPathURL error:&error];
Everything's going swimmingly.
Now I want to stop iCloud syncing for this file.
I first make sure that the file has at least been synced with iCloud by calling the following:
- (BOOL) isDataFileSyncedWithCloud
{
if (![self isICloudSupported] || ![self isUsingICloudForFiles])
return NO;
NSURL* file = [self getFileURLToCloudDatafile];
NSNumber* isInCloudNum = nil;
if ([file getResourceValue:&isInCloudNum forKey:NSURLIsUbiquitousItemKey error:nil])
{
// If the item is in iCloud, see if it is downloaded and uploaded.
if ([isInCloudNum boolValue])
{
NSNumber* isDownloadedNum = nil;
if ([file getResourceValue:&isDownloadedNum forKey:NSURLUbiquitousItemIsDownloadedKey error:nil])
{
NSNumber* isUploadedNum = nil;
if ([file getResourceValue:&isUploadedNum forKey:NSURLUbiquitousItemIsUploadedKey error:nil])
{
return ([isDownloadedNum boolValue] && [isUploadedNum boolValue]);
}
}
}
}
return NO;
}
The above returns YES, indicating the file has been synced (or so I thought...)
So, now I go ahead and make the call below to stop iCloud syncing for this file:
[[NSFileManager defaultManager] setUbiquitous:NO itemAtURL:localPathURL destinationURL:cloudPathURL error:&error];
and I get the following error: "The operation couldn't be completed. (LibrarianErrorDomain error 2 - Cannot disable syncing on a unsynced item.)"
Any idea why this error is occurring and how I can get rid of it? I would have thought that my file was fully synced...
Thanks in advance!
I figured it out. To disable iCloud syncing, I was accidentally calling:
[[NSFileManager defaultManager] setUbiquitous:NO itemAtURL:localPathURL destinationURL:cloudPathURL error:&error];
instead of
[[NSFileManager defaultManager] setUbiquitous:NO itemAtURL:cloudPathURL destinationURL:localPathURL error:&error];

Resources