3

In my iCloud-based app, I noticed that if a crash were to occur while a UIDocument is open (and has not yet been closed), the status of the document sometimes becomes UIDocumentStateSavingError and it never opens successfully again.

When I run [UIDocument openWithCompletionHandler:] after this, the document never opens, returning NO for success and 5 (UIDocumentStateClosed and UIDocumentStateSavingError) for documentState.

On iOS 5, I also observed that NSMetadataQueryDidUpdateNotification is constantly being called (every second) until the file is deleted and the app is restarted. This causes additional usability problems in the app.

One more thing, on developer.icloud.com I noticed that the file is showing a second, conflicted version existing. This conflict isn't found on any of my devices, though, not even if the app is restarted or reinstalled.

What do I do to get the UIDocument to open normally?

Here is what I tried so far:

  • Checking [NSFileVersion unresolvedConflictVersionsOfItemAtURL:] for conflicts and removing all older version using [NSFileVersion removeOtherVersionsOfItemAtURL:].

  • Calling [[NSFileManager defaultManager] evictUbiquitousItemAtURL:] before calling [UIDocument openWithCompletionHandler:] to re-download the file to the device.

  • Downloading the main and conflicted versions from developer.icloud.com to see if any of them are corrupt or partial files. Both open fine.

  • Banging my head against my desk. Preliminary results are unsuccessful.

Anton
  • 3,998
  • 25
  • 40
  • I've fixed similar issues using the "evictUbiquitousItemAtURL". Are you checking for success or is it throwing an error? – Mike M Mar 13 '13 at 21:45
  • Both: `evictUbiquitousItemAtURL:` returns `YES` and does not produce an error for me. – Anton Mar 13 '13 at 21:50
  • Are you using a metaquery to get the document name? Sometimes when a save fails it leaves a partial file and that's one of the files returned by the query – Mike M Mar 13 '13 at 21:54
  • Yes, I am. If it's a partial file, would `evictUbiquitousItemAtURL:` not get rid of it and re-download, though? – Anton Mar 13 '13 at 21:55
  • I don't think it does. When I ran into a similar problem, I solved it using the answer I posted here: http://stackoverflow.com/questions/15338371/warning-in-icloud-integration – Mike M Mar 13 '13 at 21:56
  • btw, the evict just gets rid of the local copy, so it would just download the same broken file again I think. – Mike M Mar 13 '13 at 21:58
  • Wait... so you're saying that the crash could permanently corrupt the file? – Anton Mar 13 '13 at 22:00
  • Also, I have 6 test devices, and every time I have this problem it correctly opens on a few of them and not others. This must mean the file is isn't corrupted somewhere. As I mentioned, on developer.icloud.com it shows a conflict that none of the devices pick up. – Anton Mar 13 '13 at 22:01
  • I would guess that the devices that work have a local copy that is fine - the broken copy is probably the "latest" and every other device that syncs after that gets the "bad" file. This is speculation, but is based on what I've seen. – Mike M Mar 13 '13 at 22:03
  • I think a crash doesn't "permanently" corrupt the file as much as it loses the last changes. – Mike M Mar 13 '13 at 22:04
  • I see what you mean, though one of the tests I did involved letting changes sync for a while, and everything synced--but the "bad" files didn't. – Anton Mar 13 '13 at 22:05
  • I also found that copying the "bad" file locally and opening the copy works (this is done programmatically as a test, iCloud is not turned off). – Anton Mar 13 '13 at 22:11

0 Answers0