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.

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?