User Profile

I'm writing a Swift wrapper for Search Kit and ran into a problem. Let's say I have indexed a single document: /documents/hello.txt Now the user moves the document to another folder: /notes/hello.txt How can I update the index after a document was moved without having to re-index the document? There is SKIndexMoveDocument(), but it requires a new parent SKDocument. How would I get a reference to that? I tried creating it via SKDocumentCreateWithURL, but updating the index fails. I assume, because there is no document with the path "/notes/" in the index (it's a folder after all)? The SearchKit Programming Guide says that when moving a document, one should remove the old document from the index and add it again with the new URL. There has to be a better way without having to reindex. Imagine renaming the root folder of a large document tree. Re-indexing all files would be unnecessary if only their URLs changed.

Starting with iOS 13 I'm receiving error reports from users that cannot open their iCloud documents anymore. The error is each time: Error Domain=NSCocoaErrorDomain Code=256 "The file “Untitled.txt” couldn’t be opened." UserInfo={NSURL=file:///private/var/mobile/Library/Mobile%20Documents/iCloud~com~myapp/Documents/Untitled.txt}Code 256 means: NSFileReadUnknownErrorRestarting the device solves the problem each time, but I get a lot of error reports. My app does check the availability of iCloud documents (it uses file coordination and UIDocument). This used to work fine before iOS 13.Has anybody seen a similar issue? What could be causing this and how could I collect more useful debug information to get to the bottom of this?

Starting with Catalina Beta 6 and now with Beta 7 I’m seeing the following error in my Mac app when I try to write an NSFileWrapper to disk:ObjC:-[NSFileWrapper regularFileContents] tried to read the file wrapper's contents lazily but an error occurred: The file “problem.txt” couldn’t be opened because you don’t have permission to view it.Swift:Error Domain=NSCocoaErrorDomain Code=257 "The file “problem.txt” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=/Users/test/Library/Caches/03B8158C-31C2-4CCA-8CCF-327E4EC7CCE3.bundle/problem.txtI can reproduce this in a sample app. Here is what the sample app does:(1) It creates the following sample folder: ~/Library/Caches/<UUID>/ test.txt problem.txt(2) It initializes a new NSFileWrapper with the folder.(3) It removes the child file wrapper “problem.txt” and adds it again (to simulate an update)(4) It writes the file wrapper to disk for the first time (this works)(5) Right away it writes the file wrapper to disk a second time. This fails each time with the error above.This is a serious issue, because it results in data-loss for all users of my app (sandboxed, Mac App Store) that are running the latest Catalina beta. I can also reproduce this in a sample app that is not sandboxed. Interestingly enough, the problem does not occur in the sample app when I enable sandboxing here.Back in the day, the macOS High Sierra beta build 17C88 contained a similar issue which was fixed in the official release. This looks like it could be a regression.References:REFERENCES:- FB5353407: macOS High Sierra beta bug report- FB7101246: macOS Catalina beta 6 bug report- FB7164053: macOS Catalina beta 7 bug reportTo reproduce, run the code below in a new Cocoa app (not sandboxed): import Foundation class FileWrapperTestCaseSwift { func reproduce() { // Prepare sample data: // ~/Library/Caches/<UUID>/ // test.txt // problem.txt let sampleDataFolderURL = temporaryDataFolderURL() try! FileManager.default.createDirectory(at: sampleDataFolderURL, withIntermediateDirectories: true, attributes: nil) try! "test" .write(to: sampleDataFolderURL.appendingPathComponent("test.txt" ), atomically: true, encoding: .utf8) try! "problem".write(to: sampleDataFolderURL.appendingPathComponent("problem.txt"), atomically: true, encoding: .utf8) // Read sample data: let mainFileWrapper = try! FileWrapper(url: sampleDataFolderURL, options: []) // Simulate a change: updateFileWrapper(mainFileWrapper) NSLog("About to write file wrapper for first time") try! mainFileWrapper.write(to: sampleDataFolderURL, options: .atomic, originalContentsURL: sampleDataFolderURL) updateFileWrapper(mainFileWrapper) NSLog("About to write file wrapper a second time.") do { // This fails on macOS Catalina Beta 6 & 7: try mainFileWrapper.write(to: sampleDataFolderURL, options: .atomic, originalContentsURL: sampleDataFolderURL) NSLog("Test PASSED") } catch { fatalError("TEST FAILED. Error: \(error)") } } private func updateFileWrapper(_ mainFileWrapper:FileWrapper) { mainFileWrapper.fcRemoveFileWrapperWithName("test.txt") mainFileWrapper.fcAddRegularFileNamed("test.txt", data: "test".data(using: .utf8)!) #warning ("*** This file wrapper causes problems:") if mainFileWrapper.fileWrappers?["problem.txt"] == nil { // For some reason, this file wrapper will cause problems the second time the parent // file wrapper is written to disk. The file wrapper test.txt is removed and added each time // to simulate an "update" in the app. Whereas problem.txt remains unchanged and is only added once. // Error: Error Domain=NSCocoaErrorDomain Code=257 "The file “problem.txt” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=/Users/test/Library/Caches/03B8158C-31C2-4CCA-8CCF-327E4EC7CCE3.bundle/problem.txt, // Error in console: -[NSFileWrapper regularFileContents] tried to read the file wrapper's contents lazily but an error occurred: The file “problem.txt” couldn’t be opened because you don’t have permission to view it. mainFileWrapper.fcAddRegularFileNamed("problem.txt", data: "problem".data(using: .utf8)!) } } private func temporaryDataFolderURL() -> URL { let cachesPath = NSSearchPathForDirectoriesInDomains(.cachesDirectory, .userDomainMask, true).first ?? NSTemporaryDirectory() let tempDocumentName = UUID().uuidString + ".bundle"; return URL(fileURLWithPath: cachesPath, isDirectory: true).appendingPathComponent(tempDocumentName) } } extension FileWrapper { func fcRemoveFileWrapperWithName(_ name:String) { if let fileWrapper = fileWrappers?[name] { removeFileWrapper(fileWrapper) } } func fcAddRegularFileNamed(_ name:String, data:Data) { let child = FileWrapper(regularFileWithContents: data) child.preferredFilename = name addFileWrapper(child) } }

A week ago I released an update to my iOS app and suddenly my app crashes at [NSMetadataItem valueForAttribute:] for users still running iOS 9.3.x.I did not touch any iCloud related code in my app and changed a completely different part for the update, so I'm puzzled why the app is crashing all of a sudden (no such crashes were reported in previous versions).The app only seems to crash on iOS 9.3.x. The other thing that changed is that I now build against the iOS 12.1 SDK. Could there be a bug in the iOS SDK (or iOS 9) that could cause this bug to surface?Below is the relevant part of the crash log.I'm grateful for any hints or suggestions.Hardware Model: iPad3,1 Code Type: ARM (Native) Parent Process: launchd [1] OS Version: iOS 9.3.5 (13G36) Report Version: 105 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x00000010 Triggered by Thread: 0 Global Trace Buffer (reverse chronological seconds): 7.532444 CFNetwork 0x000000002296f87d TCP Conn 0x156325c0 complete. fd: 4, err: 0 7.534582 CFNetwork 0x0000000022970977 TCP Conn 0x156325c0 event 1. err: 0 Thread 0 name: Thread 0 Crashed: 0 libswiftCore.dylib 0x0076e52e 0x50a000 + 2508078 1 Foundation 0x22babfac -[NSBundle classNamed:] + 80 (NSBundle.m:1200) 2 CloudDocs 0x305451d6 __34+[BRContainerCache containerCache]_block_invoke + 58 (BRContainer.m:2254) 3 libdispatch.dylib 0x21f5d80e _dispatch_client_callout + 22 (init.c:819) 4 libdispatch.dylib 0x21f6f172 dispatch_once_f$VARIANT$mp + 62 (once.c:60) 5 CloudDocs 0x30545198 +[BRContainerCache containerCache] + 60 (once.h:68) 6 CloudDocs 0x30539daa -[NSURL(BRAdditions) br_cloudDocsContainer] + 58 (NSURL+BRAdditions.m:398) 7 CloudDocs 0x3052ffe0 __25+[BRQueryItem initialize]_block_invoke_24 + 40 (BRQueryItem.m:224) 8 Foundation 0x22bb8a80 -[NSMetadataItem valueForAttribute:] + 160 (NSMetadata.m:172)