Actually, what prompted me to write this post and I forgot to mention is that the user told me that they can remove the folders without errors in the Finder. So I was also wondering if the Finder is using its own recursive folder delete function, and if I should be doing so as well to be safe?

Thanks, I posted at https://forums.swift.org/t/improve-filemanager-contentsequal-atpath-speed/80972

You don't want to end up unnecessarily copying to the system volume when you could have cloned by staying "inside" the correct file system. I don't understand. Doesn't URLResourceKey.volumeSupportsFileCloningKey allow me to detect if cloning is supported? on the smb side, I don't think there's currently any way to preserve file clones across the smb copy, even when both sides support cloning I thought you were saying that with the deprecated Carbon API one can clone files, but then I don't understand why file clones are not preserved. Do you mean when copying a folder that contains file clones, those files are copied and not cloned?

I also created FB17274101 back in April 2025.

Do you agree, and have another suggestion for what the issue could be?

Makes perfect sense now. Thank you for your insights.

Thanks. Sure, I just meant that it seems a little "unclean" to have a temporary file on a volume that is not controlled by the OS and could potentially be lying there forever if the volume is disconnected in the middle of the operation. I'm going to be using URLResourceKey.volumeSupportsFileCloningKey to determine if cloning is available and use clonefile in that case, and otherwise use filecopy to copy the file to the system temporary directory and then copy it from there to the actual destination volume. The latter may be a problem if it's a big file for which the system volume has not enough free space, but in that case the user should just disable checksum calculation in my app.

I didn't receive some notifications for recent replies to my posts. Were notifications disabled during the WWDC25 week? I'm not sure I understand the difference between "temporary" and "working (with in progress files)". Wouldn't the temporary one be for in progress files too? And do you mean that I shouldn't use the temporary folder in a production app?

I just discovered RunLoop.current.perform(_:). I guess that would be the correct way to go?

Thanks for the explanation. So is using perform(_:with:afterDelay:) or Timer.scheduledTimer(withTimeInterval:repeats:block:) the correct way in this case? I thought using DispatchQueue.main.async was the most elegant way, as it's succinct and allows me to call a native Swift method with a native Swift argument, but because of the modal table view unresponsiveness it's out of the question. Timer.scheduledTimer(withTimeInterval:repeats:block:) is less intuitive and a little longer, but works in this case, so it's my best option for now. perform(_:with:afterDelay:) requires the first argument to be a @objc method, which in turn requires its own argument to be representable in Objective C (which I did by inheriting from NSObject, quite an overhead).

Even with 16.4 I'm still having ~22% CPU after doing nothing for many minutes, and Xcode has already been running for a while.

In the meantime somewhere I found a workaround. In my case, the issue happened because I was sharing files from my Documents folder, which is somehow protected. Copying the file to the home folder and sharing it from there worked. I would still have appreciated a reply from Apple though.

I just wanted to clarify one thing. I've been using NSFileCoordinator for copying files for quite some time now, i.e blocking for the duration of the file copy operation. Did you mean that I shouldn't be doing that, since copying a file can potentially take more than 1 second?

I actually thought of that third possibility while I started reading your post. It's so obvious that I couldn't possibly see it before. I'm now thinking that cloning a file before copying it to the target volume and then calculate the checksum on the clone is the best solution when the source volume is the root file system, because then I can create the clone in the user's temporary directory. In theory it would be sufficient if the source volume simply supports file cloning, but it feels a little ugly creating a temporary clone on a source volume that doesn't have a temporary system directory.

Thanks for your detailed explanations. My app allows to sync directory pairs and can be considered a backup app, since one of the two directories can be the backup (on an external volume). Wouldn't this qualify it for that entitlement? The reason why I'm considering cloning the source directory is that I would like to add an option to calculate the checksum for each source file so that the app can check at certain points in time if the backup files are corrupt. This would be problematic if between copying the source file to the backup volume and calculating the checksum of the source file, the source file is changed (either by the user, or by other apps, such as Photos, which regularly updates its database). The app would make a bad impression if the copied files would immediately be flagged as corrupt because the checksum was calculated on a different version of the source file. From what I understand I should avoid cloning an arbitrary, user-selected directory, and the only efficient solution I see is to create a source volume snapshot. The other, much less efficient solution that comes to my mind would be to check that the checksum of the backup file corresponds to the checksum of the source file calculated before the copy operation, and if it doesn't, copy the file again until it does.