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 the discussion, it will be helpful in deciding how to handle long operations.

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.

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.

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.

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.

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

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.

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.

For a different app of mine I was thinking of how I can include interesting data in a crash report. One thing that came to my mind, and seems to work, is to set the current thread's name with Thread.current.name = (Thread.current.name ?? "") + ". Invalid index \(i) for count \(array.count)" All thread names are included in the crash report. I don't think this is a good idea (and I'm surprised this even works, thinking of the privacy implications). Am I allowed to do this and is there a better alternative? The messages passed to preconditionFailure and fatalError are not included in the crash report.

Changing the order of the file formats in the Info.plist file is reflected in the save panel popup button, and putting Markdown before Plain Text solves this particular issue. But it seems that regardless which file format is selected in the save panel, the produced file always gets the .md extension.

I just tried, but it doesn't change anything. The documentation also states that it already returns true by default.

allowsOtherFileTypes alone makes the file format popup button appear, but then setting accessoryView makes it disappear again. Is it possible to have both? override func prepareSavePanel(_ savePanel: NSSavePanel) -> Bool { savePanel.allowsOtherFileTypes = true savePanel.accessoryView = NSTextField(labelWithString: "asdf") return true }

It would still be great if an Apple engineer could comment on whether this can indeed happen (and when) or if it's likely a macOS issue. Not only was clickedRow outside of the valid index range, but it was also not -1, and I thought that it would only be set for the duration of table view action methods (e.g. context menu item actions, double click action), not during methods called by buttons outside of the table view.

I'm not sure anymore, but it's possible that it had two rows at some point. Then I would have clicked a button that changed the data source array and the table view would have been reloaded with reloadData(). And in the end I clicked another button to add a new item to the data source array and insert the corresponding row in the table view, but since clickedRow was invalid, it crashed. I have been using NSTableView for different apps for more than 10 years now so I have some experience with it, and the implementation in this case is quite simple. array is the one that can gets swapped whenever category changes, and otherArray is another one that is displayed when no category is selected. func numberOfRows(in tableView: NSTableView) -> Int { return array.isEmpty ? 0 : category.map({ array[$0]?.count ?? 0 }) ?? otherArray.count } func tableView(_ tableView: NSTableView, viewFor tableColumn: NSTableColumn?, row: Int) -> NSView? { let cell = MyTableCellView() ... return cell } func tableView(_ tableView: NSTableView, rowActionsForRow row: Int, edge: NSTableView.RowActionEdge) -> [NSTableViewRowAction] { ... } func tableView(_ tableView: NSTableView, shouldSelectRow row: Int) -> Bool { ... } func tableViewSelectionDidChange(_ notification: Notification) { ... }