Posts

Post not yet marked as solved
4 Replies
634 Views
Normally iCloud documents can be opened when off-line. However, with ios 13, if you have an active SMB server connection in the Files App, and then the network is disabled, calls to UIDocument initWithFileURL: block indefinitely while attempting to lookup file attributes.Note calls to [UIDocument openWithCompletionHandler:], [NSURL getResourceValue:forKey:error:] and ExternalProviderPrepareValues.Backtrace:Thread 1 name: Dispatch queue: UIDocument File Access Thread 1: 0 libsystem_kernel.dylib 0x00000001b493a784 mach_msg_trap + 8 1 libsystem_kernel.dylib 0x00000001b4939ba8 mach_msg + 76 2 libdispatch.dylib 0x00000001b482bf10 _dispatch_mach_send_and_wait_for_reply + 552 3 libdispatch.dylib 0x00000001b482c304 dispatch_mach_send_with_result_and_wait_for_reply + 56 4 libxpc.dylib 0x00000001b476b96c xpc_connection_send_message_with_reply_sync + 240 5 Foundation 0x00000001b507a398 __NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__ + 16 6 Foundation 0x00000001b4e40834 -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2668 7 Foundation 0x00000001b4e6faa8 -[NSXPCConnection _sendSelector:withProxy:arg1:arg2:arg3:] + 148 8 Foundation 0x00000001b50814a4 _NSXPCDistantObjectSimpleMessageSend3 + 48 9 FileProvider 0x00000001c93b6ba4 -[FPDaemonConnection valuesForAttributes:forItemAtURL:error:] + 428 10 FileProviderOverride 0x000000010e5b9f14 0x10e5b8000 + 7956 11 CoreFoundation 0x00000001b4b7cf14 __invoking___ + 148 12 CoreFoundation 0x00000001b4a46098 -[NSInvocation invoke] + 400 13 CoreFoundation 0x00000001b4a46cc0 -[NSInvocation invokeWithTarget:] + 80 14 FileProvider 0x00000001c9374db8 -[FPFrameworkOverridesIterator callNextOverrides] + 468 15 FileProvider 0x00000001c9374f58 -[FPFrameworkOverridesIterator forwardInvocation:] + 96 16 CoreFoundation 0x00000001b4b7a7d8 ___forwarding___ + 680 17 CoreFoundation 0x00000001b4b7cd60 _CF_forwarding_prep_0 + 96 18 FileProvider 0x00000001c9394cc0 FPCFCopyAttributeValuesForItem + 300 19 CoreServicesInternal 0x00000001b5ebba98 CopyFromFileProvider+ 154264 (__CFURL const*, void const*, void const**, __CFError**) + 88 20 CoreServicesInternal 0x00000001b5ebbe40 ExternalProviderPrepareValues+ 155200 (__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) + 376 21 CoreServicesInternal 0x00000001b5ea8cc0 prepareValuesForBitmap+ 76992 (__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) + 376 22 CoreServicesInternal 0x00000001b5ea69d4 _FSURLCopyResourcePropertyForKeyInternal+ 68052 (__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) + 220 23 CoreFoundation 0x00000001b4b40768 CFURLCopyResourcePropertyForKey + 140 24 CoreFoundation 0x00000001b4a4d190 -[NSURL getResourceValue:forKey:error:] + 120 25 Foundation 0x00000001b4ec43a0 +[NSFileVersion unresolvedConflictVersionsOfItemAtURL:] + 124 26 UIKitCore 0x00000001b86fcc90 -[UIDocument _setOpen:] + 144 27 UIKitCore 0x00000001b86fbb8c __40-[UIDocument openWithCompletionHandler:]_block_invoke + 676 28 libdispatch.dylib 0x00000001b4814ec4 _dispatch_call_block_and_release + 32 29 libdispatch.dylib 0x00000001b481633c _dispatch_client_callout + 20 30 libdispatch.dylib 0x00000001b481c85c _dispatch_lane_serial_drain + 568 31 libdispatch.dylib 0x00000001b481d290 _dispatch_lane_invoke + 400 32 libdispatch.dylib 0x00000001b4826928 _dispatch_workloop_worker_thread + 584 33 libsystem_pthread.dylib 0x00000001b487d714 _pthread_wqthread + 276 34 libsystem_pthread.dylib 0x00000001b48839c8 start_wqthread + 8Note the app doesn't use a Document Browser: UISupportsDocumentBrowser = FALSE. LSSupportsOpeningDocumentsInPlace = FALSE Using a single NSUbiquitousContainer with NSUbiquitousContainerIsDocumentScopePublic = FALSE
Posted
by michaelr.
Last updated
.
Post not yet marked as solved
2 Replies
447 Views
My app stores data files in a ubiquity container. NSUbiquitousContainerDocumentScopePublic is FALSE. After accessing a file from within the app, it is now showing in the Recent files area of the Files app. I would expect that because the ubiquitous container scope is private this should NOT occur. I'm seeing this for other apps that also would not normally be exposing internal files. Anyone else experiencing this? I have filed feedback with Apple and awaiting response.
Posted
by michaelr.
Last updated
.
Post not yet marked as solved
0 Replies
253 Views
I'm developing a autoFill credential provider extension.The extension uses an iCloud file which is sharing data between the main application and the extension. Reusing the code to manage iCloud files, I'm not seeing any notication that iCloud has been disabled (or reenabled) for the main application inside the extension.This issue is made worse by the fact that extensions may be terminated - or not. So whilst an extension continues to run it appears to maintain the same iCloud state from startup. Calls to NSFileManager.defaultManager.ubiquityIdentityToken always return the same value within the extension (and NSUbiquityIdentityDidChangeNotification is never posted). This means after informing the end user that iCloud needs to be enabled, it is unable to detect that it has been enabled, until the extension process is eventually terminated and then restarted.
Posted
by michaelr.
Last updated
.
Post not yet marked as solved
1 Replies
678 Views
I have an app that uses NSPersistentDocument (without autosaving) on OS X and UIDocument (also without autosaving) on iOS. The file representation is Binary Core Storage. This app has been working fine since iOS 7 + macOS 10.10.If I open a document on OS X 10.13, and another device (macOS 10.13 or iOS 11) opens the same file, on the next save I get a warning "This document's file has been changed by another application since you opened or saved it.". The warning is spurious, because only an open has occured on another device - not a save.In looking for a possible reason for this notification, I notice that when an iCloud file open occurs on one device, an extended attribute named com.apple.lastuseddate#PS is updated. I have confirmed this extended attribute is updated on both iOS 11 and macOS 10.13. This extended attribute doesn't appear to have been used in prior versions of iOS or macOS. I wonder if the updating of file metadata is triggering this spurious warning.(I suspect this attribute may related to NSFileProvider on iOS 11 as there is a new method setLastUsedDate:forItemIdentifier:completionHandler: and FinderSync on macOS 10.13 as setLastUsedDate:forItemWithURL:completion: is also new.)My question is - do others see this new behavior? Is it causing others such annoying side effects?
Posted
by michaelr.
Last updated
.