The issue is that, when I try to reproduce this on a VM, it doesn’t happen. I tried using a VM (I haven't done so in a very long time), but when trying to download Xcode in it, the App Store kept telling me that my password was wrong, so I couldn't get further. While this is annoying, it isn't at all surprising to me: I wanted to transition from using separate partitions for each old macOS version (to test my apps) to using VMs instead, but quickly noticed that a VM may not reproduce all issues found on a "real" macOS installation, and vice-versa. So up to this day I create a new separate partition on an external drive for each new major macOS version. While installing a new partition blocks you from using your Mac for some time, in my opinion it's worth having separate partitions to test things on, since in my experience a VM is not nearly as accurate as the real thing. In alternative, could creating a new user be an alternative for you? I just remembered that Apple Care always asks to test things with a different user.

[quote='852565022, Etresoft, /thread/795994?answerId=852565022#852565022, /profile/Etresoft'] it would have shown up in the top-level list, not in "Other" [/quote] I didn't say that. The app does show up in the top-level list, as I mentioned: "When choosing my app in the "File > Open With" menu, the file opens just fine in my app". And, by extension, you wouldn't be getting that malware warning either. Unless it's a macOS issue as confirmed by a macOS engineer.

Does your app explicitly advertise support for this file type in imported file types? It does. I tried only with public.text as well as adding net.daringfireball.markdown (imported with an "equivalent type" with extension "md"), both didn't work.

[quote='849011022, DTS Engineer, /thread/792033?answerId=849011022#849011022'] By design, the FileManager won't remove objects marked immutable, which would also prevent directory removal. [/quote] Good guess, but that wasn't the issue, even though it would have made a lot of sense. It's unfortunate I left that part of the code in there, but the user actually tested my App Store app with and without unlocking locked files (the app contains a switch for that), which didn't help, and they sent me plenty of screenshots and videos which show that the files are not locked.

I see, thanks. I'd prefer to stay away from deprecated APIs, but if a user complains about the speed when copying between SMB volumes, I'll come back to this topic. Perhaps the only remaining question would be: how would I find out if the Carbon API / the SMB volume effectively supports cloning, or is it not possible?

Thanks for your insights. how long is the deepest file path? Not long. In the video they showed how the removed directory is only 2 levels deep and every filename is 10-20 characters long. Are you able to remove the sub-directory they added? Like I mentioned, with FileManager.removeItem(atPath:) I wasn't able to, but with my custom function below that recursively removes files before the containing folder and I sent to them in a test app today, it worked (and no error alerts were shown). (Note: before macOS 10.15, the code will leave empty sub-directories and try to remove the top-level directory at the end.) func removeFileRecursively(atPath path: String) -> Bool { if case let url = URL(fileURLWithPath: path, isDirectory: false), (try? url.resourceValues(forKeys: [.isDirectoryKey]).isDirectory) == true { var options: FileManager.DirectoryEnumerationOptions = [] if #available(macOS 10.15, *) { options.insert(.includesDirectoriesPostOrder) } guard let enumerator = FileManager.default.enumerator(at: url, includingPropertiesForKeys: [.isDirectoryKey, .isUserImmutableKey], options: options, errorHandler: { url, error in NSAlert(error: error).runModal() return true }) else { return false } while let url = enumerator.nextObject() as? URL { let isDirectory = (try? url.resourceValues(forKeys: [.isDirectoryKey]).isDirectory) == true let shouldRemove = if #available(macOS 10.15, *) { !isDirectory || enumerator.isEnumeratingDirectoryPostOrder } else { !isDirectory } if shouldRemove { do { if try url.resourceValues(forKeys: [.isUserImmutableKey]).isUserImmutable == true { try (url as NSURL).setResourceValues([.isUserImmutableKey: false]) } if #available(macOS 10.15, *) { let result = if isDirectory { rmdir(url.path) } else { unlink(url.path) } if result < 0 { throw NSError(domain: NSPOSIXErrorDomain, code: Int(errno)) } } else { try FileManager.default.removeItem(at: url) } } catch { NSAlert(error: error).runModal() return false } } } } do { try FileManager.default.removeItem(atPath: path) } catch { NSAlert(error: error).runModal() return false } return true }

[quote='848663022, DTS Engineer, /thread/791665?answerId=848663022#848663022'] This is a known limitation of the macOS smb client [/quote] Thanks for confirming. Hopefully one day it will be implemented. I created FB18783115.

The user sent me a video showing how removing regular files and empty directories works, but removing non-empty directories doesn't work. They even created a new directory, put a file in there and tried to remove the directory: it didn't work, and after moving the contained file away, it worked.

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.