I just had this issue again on my own Mac with macOS 15.2. My app had been active for a while and had been able to resolve bookmarks. Then suddenly when trying to create new bookmarks I got the usual error. Restarting the app solved the issue.

Do you mean to the main target or the app extension? And should I keep the existing Localizable.xcstrings or delete it?

Here's a link to a sample project: https://www.swisstransfer.com/d/e8ad8888-ae2e-4371-8e82-0d5915c967c7 I really just created an empty macOS App project, added a target App Intents Extension named CompareIntent, and pasted the code I provided above in the CompareIntent.swift file. Then I build the project and copied the app into my Applications folder, and I can still reproduce the issue when running the app intent in Shortcuts.

[quote='817975022, DTS Engineer, /thread/767019?answerId=817975022#817975022'] Dispatching to the main thread (with a Swift Task) is an anti-pattern in this case [/quote] Correct, and as I mentioned, this poses the question of how to avoid race conditions when accessing my custom data needed both in SceneKit and in SpriteKit (since the first uses its own thread, and the latter is annotated @MainActor).

In the meantime I already filed FB15737374 and opened Case-ID 10297510 to discuss a different issue I'm having, and the TSI engineer suggested as a workaround to update the SpriteKit scene in its SKScene.update(_:) method (although the delegate methods seem to work as well), which poses the question of how to avoid race conditions when accessing my custom data needed both in SceneKit and in SpriteKit (since the first uses its own thread, and the latter is annotated @MainActor). For now, it is proving to be a difficult conversation.

[quote='815279022, DTS Engineer, /thread/769257?answerId=815279022#815279022'] I don't know where the VFS driver got that st_size from, but returning a size >~18 Exabytes seems like an unusual choice. [/quote] Thanks for pointing out the size issue. Today Paragon got back to me and confirmed that the developers will fix the wrong size returned for symbolic links.

After replacing the .heic images with .png ones, it finally worked.

[quote='815147022, DTS Engineer, /thread/766035?answerId=815147022#815147022'] SO, making sure this is clear, the performance "trick" here is to use your final scan storage format as your "intermediate" format instead of doing the entire scan in memory. If done properly, this means: [/quote] I'm not sure I understand. Do you mean that you would write the scan results to disk while the scan is in progress? Otherwise I don't get the "entire scan in memory" part. You're probably right that resuming a scan is easier in the iterative case. I'm not supporting that case (yet), so for now I'll stick to recursion.

[quote='813377022, floorish, /thread/764435?answerId=813377022#813377022, /profile/floorish'] I've received multiple reports from users that macOS 14.7.1 cannot create new bookmarks or resolve existing bookmarks. [/quote] Today I too was contacted by a user who updated from macOS 13 to 14.7.1 and was quite desperate since my app couldn't resolve or create bookmarks anymore. Restarting the Mac didn't help. Thankfully you already reported the same issue so I suggested to update to 15.1.1, which finally solved the issue.

After some more playing around perhaps I was able to find the real issue by reducing the setPage method to this: func setPage(_ page: Int) { pageViews[self.page].run(.removeFromParent()) // pageViews[self.page].removeFromParent() self.page = page let pageView = pageViews[page] pageContainer.addChild(pageView) } When this code runs, only the second sprite becomes visible, and when the first one should appear, its space is left empty. Could SKAction.removeFromParent() be the problem? Replacing that instantaneous animation with a simple call to SKNode.removeFromParent() allows both sprites to alternate correctly.

I just installed Xcode 16.2 beta 3. I was going to test @Stephane204's issue, but even when using Xcode 16.1 I get a different compiler error for this code: class GameViewController: UIViewController, SCNSceneRendererDelegate { let node = SCNNode() nonisolated public func renderer(_ renderer: any SCNSceneRenderer, didApplyAnimationsAtTime time: TimeInterval) { node.position.x = 0 } } I don't get Main actor-isolated property 'position' can not be mutated from a nonisolated context but I get Main actor-isolated property 'node' can not be mutated from a nonisolated context which I think is a different issue, as node is in fact a property of a main actor-isolated class, so this doesn't seem like a bug to me, although I have to say that I sometimes struggle to understand Swift Concurrency.

In other words, you do a shallow enumeration of a given directory, then repeat the shallow enumeration on whatever directories you find. This is actually the same thing you'd do with getattrlistbulk. Right. For some reason I thought it would be less efficient. Have or haven't? How are you copying files? FYI, if server side copying is an issue, this post has a code snippet for that. Have. To copy files, I'm just calling copyfile. I didn't know about server-side copying, but that may explain why every now and then a user complains that my app is slow, though they never got back to me explaining their setup or comparing the speed of my app to the that of the Finder. What's the actual failure? The copy itself failing, display issue(s), etc? I'm not sure, they simply replied "I just tried [in the Finder] and it did indeed loop!" I assume the "Preparing X files" display when starting a copy operation just kept counting up On the technical, the resource usage difference can easily be quite large, since "wide" hierarchies are much more common than "deep" hierarchies That makes sense. My app does a deep scan to determine what files to copy, then copies them, and finally stores the directory hierarchy so it can be compared with the next scan. My users also assume that the app kind of runs in the background and doesn't use too much resources, so I think I'll stick to recursion for now.

[quote='795660022, DTS Engineer, /thread/759712?answerId=795660022#795660022'] You can check if a particularl file system supports it by looking for "VOL_CAP_INT_COPYFILE" from "getattrlist". [/quote] The linked documentation for getattrlist reads VOL_CAP_INT_COPYFILE If this bit is set the volume format implementation supports the (private and undocumented) copyfile() function. Is this the same copyfile function we can use today, or something else? Or was it “private and undocumented“ some long time ago? So when VOL_CAP_INT_COPYFILE is set the volume supports server-side copying, but we still have to figure out if it‘s faster than copyfile, right? How would we check that?

One of it's options is skipsSubdirectoryDescendants, which lets you disable recursion. But then I get a shallow enumeration. I still want to scan an entire directory hierarchy. The "copyfile" Unix API will let you do that but the Finder isn't using that either, which is why the Finder can do server side SMB copying, which copyfile cannot I've noticed that, which is why I've been using copyfile for a long time now myself. In terms of why the Finder isn't having issue I think you misunderstood. I said that the Finder is having the same issue.

Thanks. I already created FB15864883 two days ago, but I thought that I must be missing something since it would be unlikely that the invite API would have been around for years without a proper way to set up a game with it.