[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.

Thanks for your detailed response. Flattening sounds like a good idea, although I'm a little bit reluctant to adopt it since this would likely mean that if one day I switch to FileManager.default.enumerator(at:includingPropertiesForKeys:errorHandler:) the bug would appear again (unless it has been fixed in the meantime). The user just confirmed to me that when copying the folder in the Finder, the same looping issue occurs. So I was wondering: wouldn't FileManager.default.enumerator(at:includingPropertiesForKeys:errorHandler:) (which I assume is used by the Finder) profit from using iteration instead of recursion as well? If we put the memory benefits you mentioned aside, are there any downsides to using iteration instead of recursion?

[quote='813727022, DTS Engineer, /thread/766035?answerId=813727022#813727022'] The big difference I can think of here is that contentsOfDirectory(atPath:) only looks at the first directory level (it's "shallow", not "deep"), which means in never recurses, which significantly changes how it interacts with SMB. [/quote] Thank you very much for your detailed help. The customer agreed to run a new test app which uses FileManager.default.enumerator(at:includingPropertiesForKeys:errorHandler:) instead of recursive getattrlistbulk calls, and it loops as well. So it seems like something weird was changed in getattrlistbulk in macOS 15. Here's what they say regarding to their server model: My original server was from HP. I rebuilt it about 8-9 years ago and has nothing to do with HP, I just left the naming convention for consistency. I think the issue is likely with Windows 10 Storage Spaces. I use Storage Spaces to pool the disk space for redundancy. It’s kind of like drive mirroring. I'm somewhat happy to learn that it's not a fault in my implementation. I guess the only thing I can do now is to wait if I get any response in Feedback Assistant, right? Or can you already tell that this won't likely be fixed in a future macOS release (if it's a macOS issue at all) and is something to be fixed in the customer's setup (Windows 10 Storage Spaces, which I've never heard of before)?

I haven't had the issue since updating to macOS 15.1 and haven't got any more reports from users either, but I will update you if I do.

Thanks, I wasn't aware that you can allow apps to run from the Privacy section of the System Settings. It's kind of hidden, but I guess that's the point to discourage users from doing so? Still, there's the question: why is this warning shown for my developer-signed app, only after uploading and downloading it again from my website?

Hi @DTS Engineer , do you have any information about what is causing this crash so that we can look for a workaround? I'm close to publishing my game on the App Store, but this is one of two bugs that prevents me from doing so. Should I open a TSI? Thanks in advance for your help.

[quote='810759022, DTS Engineer, /thread/766035?answerId=810759022#810759022'] The big test I would add here is to call contentsOfDirectory(at:includingPropertiesForKeys:options:) as well or, even better, enumerate the directory with CFURLEnumeratorCreateForDirectoryURL(). Either of those should end up calling getattrlistbulk and a failure in either would be good confirmation that the problem isn't actually with your code. [/quote] Thanks for all your detailed insights. I understand that the URL version of try FileManager.default.contentsOfDirectory(atPath: path).count is faster, but both should call getattrlistbulk, and since at the very beginning I mentioned that it indeed returns a reasonable file count, it would seem that... there is indeed something wrong with my code? Although you also mentioned that you don't see any obvious failure point in it. I updated my feedback report FB15497909 on October 28 by uploading the sysdiagnose and other tests performed by the user, but haven't heard anything yet. Are you already aware of it? Are you able to tell where the issue might be?

[quote='809783022, Bill3D, /thread/766249?answerId=809783022#809783022, /profile/Bill3D'] Yes, it does crash on the iPad simulator. It didn't crash for me on the iPhone simulator [/quote] Confirmed. Thanks for the workaround.

Note: occasionally the hang doesn't happen while debugging the app in Xcode, but until now it always happened when profiling the app in Instruments.