What are you actually trying to do/capture? I'm hoping to understand the issue better by seeing what the invalid index is. My idea was to check that the index is valid, and if not, set the thread name to some debug message and then let the app crash. Even if it sounds like a bad idea, I think it's still better than keep letting the app crash without having a clue about the cause and hence being unable to fix it.

Thanks for your detailed answer. It's not my intention to implement a custom exception handler, I was just wondering about how I could include additional information in the crash report. You're right that the one I included at the beginning already says that the array is empty, I didn't even remember. I was actually thinking about Swift arrays, for which an out of bounds exception causes a crash report with only this information: Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x00000001a6002c24 Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5 Terminating Process: exc handler [28880] Hence my idea of putting the array count and the invalid index as the thread name. I got many crash reports recently because of invalid Swift array accesses and I was looking for a way of debugging them without asking the user for help, which can be helpful but I think most users would not be happy to do. but, using it as an example, it would be much safer to create a sleeping thread at launch and then rename it with "pthread_setname_np" vs. creating a new thread and naming it via NSThread. I wasn't suggesting to create a new thread and naming it, but simply naming the current thread.

That's what I thought too, but like I mentioned at the end, wouldn't Array._checkSubscript(_:wasNativeTypeChecked:) appear in the stack trace?

I just created another one, FB17662376. Yes, in the previous one I was asked to create a new one, but without giving any reason. To be honest, it can be quite irritating when you guys think that a bug has been solved and ask to verify and if it's not solved, to open a new feedback. It happens regularly. It's still the same exact issue, so why would one have to create a completely new feedback with the same data as before? It comes across as time-consuming bureaucracy.

First of all, these are two radically different use cases. Thanks for your answer, but I'm not sure I see how they are radically different use cases. If the user starts unzipping, then starts a sync, it may find the same unfinished files that can be found if the sync is triggered by FSEventStreamCreate. That's actually how you can reproduce the permission error (and which I forgot to explain earlier): Run the code I provided which will show an open panel. Start unzipping an archive which was previously created by zipping a folder named "extracted". Before the unzipping completes you select the parent folder in the open panel and click Open. The only real similarity here is that the file system is out of your control. True, hence why I was hoping in a cooperative mechanism like NSFileCoordinator which would allow to coordinate writing to the extracted folder on zip's side, and later reading it on my side. You simply have to handle them. Not so simple :-) In this case, I would handle the "permission denied" error by postponing the sync until the unzip has completed, which is the question I'm trying to find an answer to.

The end user could act as root and create an unreadable directory, leaving it there forever. In this case it would be expected that the sync results in an error. I'm only looking to handle temporary permission errors caused by running operations such as unzipping. Maybe the user runs out of disk space, or the file is corrupted, and it never completes. Ideally the unzipping operation would still allow me to detect that it has completed / aborted, e.g. by deleting the files extracted so far.

Thanks for your input. My idea of file coordination was that it would allow processes to make "atomic" changes to files and folders so that they are left in a consistent state to other processes that use file coordination as well. Unzipping seemed like an ideal fit to me, regardless how long it takes (after all, the user should be aware that an unzip operation is in progress and shouldn't worry about other scan operations containing the zip archive apparently hanging for the duration of the unzip operation). As I mentioned, I'm not trying to avoid permission errors in general, but only those caused by temporary operations such as unzipping. My app keeps syncing, sends a notification when an error happens and allows the user to see the list of errors, but the user isn't forced to do anything for the app to keep syncing. But even if the user is aware that the errors are caused by the unzip operation, they would have to go through the list of errors (which could be quite long) to make sure that they haven't overseen an unrelated error. What I could do mitigate this is to mark an error as "solved" if a successive sync of the same file is successful. If file coordination isn't the answer and the unzipped files are not meant to be accessed before the unzip operation has completed, perhaps it would make sense for unzip to write the temporary files to a standard temporary folder and then move them to the final location only at the end.

Thanks for the discussion, it will be helpful in deciding how to handle long operations.

Thanks. Here is the link to the documentation: https://manp.gs/mac/2/fs_snapshot_create (The validation message I get when trying to use a Markdown link is quite misleading: "This domain is not a permitted domain on this forums.")

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.

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.

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?

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.

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.

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