Unexplained .DS_Store files are still being created. I restarted, did a find, and found 80 new .DS_Store files in the tree that I have been looking at. Could mdsync or backupd do this?

It is looking now that deleting a .DS_Store file is unreliable. This is what I did: find . -name .DS_Store -print ; find . -name .DS_Store -exec rm {} \; ; find . -name .DS_Store -print The first print statement listed 16 files. The second print statement listed 8 files. That means 8 files were deleted and 8 were not. Hmm... I repeated the deletion step and 4 of the 8 remaining files were deleted. It seems that every other file is deleted???

I have started tracking the memory usage of the WindowServer process. In a freshly restarted system with no desktop applications other than Activity Monitor, the memory usage (as reported by Activity Monitor) is about 130 MB. Right now it is 775 MB, which is getting close to the territory where things start to hang. As applications are started and exited, the memory usage goes up and down. However, I have observed (using a script that logs the memory usage every minute) that when the system exits display sleep there can be an "instantaneous" jump in the memory usage of 100 MB or more. This additional memory usage is never reverted. By the way, I am using an Intel based iMac.

The result of not using the suspect application is that the problem did not go away, although it took longer for the problem to occur (about 5 days instead of the usual 1 or 2 days). So, the application is not the cause of the problem, but it may perform more of the operations that trigger the problem.

Did the problem of non-Apple applications losing Full Disk Access get fixed in the 11.4 release? I just noticed that an application of mine that previously had Full Disk Access somehow lost it, and I'm not aware of installing the beta on this particular system. The application got an error trying to access a file in a subdirectory under ~/Library/Autosave Information. If the application did not have an entry in the Full Disk Access list of applications, would a dialog have been displayed? That would be better than my application showing its own dialog that attempts to explain the problem and the remedy.

Good news. The importer is now working on my development system. Of course, I have no idea why. Hopefully, it will keep working. Also, I figured out the logging situation, which is not exactly as you described. First, the log messages show up on the main Console.app display, not the system.log display. Second, error messages are displayed but info messages are not, even if Action: Include Info Messages is enabled. (Is this a bug?) When I changed the basic log messages to error, they show up. Thank you for your assistance!

Regarding the problem on my development system, I ran the application from another account and Spotlight was successfully updated. So I guess that means the problem is tied to my user account. Slightly off topic, but I used fast user switching to run under the second account and found that my application would not start (*) under the second account unless I quit the application under my main account. Is that normal? *Actually, it started but immediately terminated with no logged error message.

Regarding the logging, I wrote a test app. Logging statements can be seen in the debug log under Xcode, but when run independently, nothing shows up in system.log (even looking at the file directly). #import "AppDelegate.h" #include <os/log.h> @interface AppDelegate () @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)aNotification {     os_log_t LOG = os_log_create("test.test.test", "testing");     os_log_info(LOG, "Testing OS Logging Info");     os_log_error(LOG, "Testing OS Logging Error");     os_log_info(OS_LOG_DEFAULT, "Testing OS Logging Info Default");     os_log_error(OS_LOG_DEFAULT, "Testing OS Logging Error Default");} @end

I have made some progress thanks to your suggestions. I installed the application in a clean 11.5.2 system on a VM. I waited until mdimport -L showed my importer, then saved a document. I then did a Spotlight search and the new document was successfully found! The remaining issues: Although I added logging using os_log as you suggested, I have yet to see any log messages in system.log. Any ideas on what might be going wrong? I double checked the importer binary to be sure that it contained my message strings, which it did. For example:     os_log_t LOG = os_log_create("org.violetlib.valerie", "metadata");     os_log_info(LOG, "Metadata requested for %{public}@", pathToFile); Should I expect to see this output in Console's system.log? I would really like this importer to work on my development system, but I have no desire to do a fresh OS install. Do you have any suggestions on how to get it working or how to find out which bit of persistent state is causing the problem? Thanks!

I was wondering whether it was related to the ability of my importer to write messages to the system log. I added logging to the importer but have seen no messages. What I do see is a fantastic number of messsages like this: Aug 13 06:31:00 2020 com.apple.xpc.launchd[1] (com.apple.mdworker.shared.1B000000-0500-0000-0000-000000000000[7793]): Service exited due to SIGKILL | sent by mds[95] Aug 13 06:31:00 2020 com.apple.xpc.launchd[1] (com.apple.mdworker.shared.11000000-0700-0000-0000-000000000000[7795]): Service exited due to SIGKILL | sent by mds[95] Aug 13 06:31:00 2020 com.apple.xpc.launchd[1] (com.apple.mdworker.shared.1D000000-0200-0000-0000-000000000000[7784]): Service exited due to SIGKILL | sent by mds[95] Aug 13 06:31:00 2020 com.apple.xpc.launchd[1] (com.apple.mdworker.shared.1F000000-0400-0000-0000-000000000000[7800]): Service exited due to SIGKILL | sent by mds[95]

What does this mean: Sandbox: logd_helper(614) deny(1) file-read-data /Applications/apps/Valerie.app/Contents/Library/Spotlight/ValerieSpotlightImporter.mdimporter/Contents/MacOS/ValerieSpotlightImporter

Thank you!

It might be useful to know what the real shortcut is when providing help to the user. It might also be useful to know what the real shortcut is in case it conflicts with some other use of the same key combination, in which case a different key combination can be used. An application that creates its own shortcut preferences would need to know this.