File not deleted after calling deleteDocumentWithName

[giorgioval87]

Hello everybody,
I love iCloudDocumentSync it works perfectly, but my question is:

Is there a reason why After I call deleteDocumentWithName on a valid iCloud filename, it is not deleted, and there's no error.

It seems that the cloud continues to push me the file that I'm managing to delete.

Can you help me please ?

I want to delete that file from ALL devices.

Thank you very much and again congratulations!

Giorgio

[Sam-Spencer]

I noticed this a few times during testing: UIDocument returns and calls its completion handlers without any errors, however the file does not disappear until some time after that. In my experience, it is best to use the completion handler to remove that file from your data source and update your interface. For some strange reason, the file may not delete for a while.

I'm not sure why this happens or how it can be fixed. I'll look into it more and update you if I figure anything out. If anyone has suggestions or know-how please provide it.

[BombingTim]

Do your deleted files have a 0 byte size? I recently found that if I opened a file with retrieveCloudDocumentWithName:completion: and then later on tried to delete it with deleteDocumentWithName:completion: then it would delete the file but then quickly replace it with a 0 byte file. The reason for this is the UIDocument object is still open.

I found that if i call saveAndCloseDocumentWithName:withContent:completion: then (as the method name states) it closes the UIDocument and I can delete the file as expected.

I also tried just closing the UIDocument after the retrieveCloudDocumentWithName call but that was not working for me. So I ended up writing my own function to open the file, extract the NSData, close the file and then just return the NSData since my app didn't really care about the UIDocument object and I didn't want to always have to save the file to close it.

You can check out my fork to see what I did. The code is a bit messy right now but I hope to clean it up soon. Look for the retrieveCloudDataWithName:completion: method in iCloud.m

I hope this helps!

[giorgioval87]

Hello, thank you for the support,
I'll check the file size and let you know.
my actual rivisited code is

   for (NSString* fileNameToDelete in toDeleteFileNames) {
            BOOL fileExists = [[iCloud sharedCloud] doesFileExistInCloud:fileNameToDelete];
            if (fileExists == YES) {
                    [[iCloud sharedCloud] retrieveCloudDocumentWithName:fileNameToDelete completion:^(UIDocument *cloudDocument, NSData *documentData, NSError *error) {
                    [cloudDocument closeWithCompletionHandler:^(BOOL success){
                        if (success) {
                            [[iCloud sharedCloud] deleteDocumentWithName:fileNameToDelete completion:^(NSError *error) {
                                if (error != nil) {
                                    NSLog(@"ERROR DELETING %@", fileNameToDelete);
                                }else{
                                    NSLog(@"DELETED %@", fileNameToDelete);
                                }
                            }];
                        }
                    }];
                }];
            }
        }
        return;

this is working sometimes but some other times loops because it is inside the

• (void)iCloudFilesDidChange:(NSMutableArray *)files withNewFileNames:(NSMutableArray *)fileNames

I'm evaluating the option of

• renaming all the files to delete
• try to delete them only one time , at start time
• ignore them during the app logic

this is not clear as I want, I hope to resolve this issue in other manner

Thank you again

[Sam-Spencer]

@giorgioval87 I'm working on a fix for this (sorry for taking so long to get back to you) now. I noticed that there were some issues with iCloudFilesDidChange: - so I've made some major improvements to that in 7.3 (coming soon - see Issue #37 for more information on this).

Did you ever find a solution or pinpoint the problem? I hope to resolve the issue soon.