Are there any known reasons why a single NSFilePresenter instance has its presentedItemDidChange function called twice when the contents of the file is rewritten just once?
Big Sur 11.2.3
I have extracted out the functionality into a reader and writer app and currently can't reproduce the issue in a simplified case.
But when it is put into a full app context, I can see that two separate threads are initiating the call to presentedItemDidChange(). Checking file size and date modified show that they should be identical files. Only writing a string into a file, so not changing the file in any other way. So it doesn't seem to be two changes being made to the file.
I only have one instance of the NSFilePresenter, it is referencing a file, not a directory.
Breakpointing at presentedItemDidChange shows that the framework is going through an identical call sequence. But it's happening in two different threads.
Not currently using any file coordination since there's only one file and one write operation. The meta data would suggest that it's not emptying the file, then writing it, causing two events 1) when the file size goes to zero and then 2) when the file is written and closed.
Checking the file presenter object, and there's only one instance and the same sender object is defined.
So it looks like the framework is triggering twice from two different threads. I don't have multiple processes or multiple file presenters. So unclear why two different threads are originating this.
Big Sur 11.2.3
I have extracted out the functionality into a reader and writer app and currently can't reproduce the issue in a simplified case.
But when it is put into a full app context, I can see that two separate threads are initiating the call to presentedItemDidChange(). Checking file size and date modified show that they should be identical files. Only writing a string into a file, so not changing the file in any other way. So it doesn't seem to be two changes being made to the file.
I only have one instance of the NSFilePresenter, it is referencing a file, not a directory.
Breakpointing at presentedItemDidChange shows that the framework is going through an identical call sequence. But it's happening in two different threads.
Not currently using any file coordination since there's only one file and one write operation. The meta data would suggest that it's not emptying the file, then writing it, causing two events 1) when the file size goes to zero and then 2) when the file is written and closed.
Checking the file presenter object, and there's only one instance and the same sender object is defined.
So it looks like the framework is triggering twice from two different threads. I don't have multiple processes or multiple file presenters. So unclear why two different threads are originating this.