In general, you shouldn’t ship the .tbd file in your final product. I'm not sure what you mean by final product. In this case, my final product is a framework, and the immediate "customers" for that product are developers. The developers would be building things that use the framework (compile time role) and/or including it in applications (run time role). So, if I combine various things you have written, it sounds like a reasonable choice is for me to imitiate what the current Xcode does when it builds a framework. That means creating a V4 .tbd file with no UUIDs. Yes?

I like that answer! My explanation is a bit complicated. As you may know, the JavaNativeFoundation framework does not run natively on arm64. So, I am trying to figure out how to compile the open-source for it in a way that can be used on all architectures and macOS releases back to 10.10. I found that the only way to compile a framework to support 10.10 was to use an old version of Xcode (13.4.1 worked). When I build the framework using that Xcode, it creates a .tbd that includes UUIDs. Instead of using an old Xcode, I thought I would instead create the package using individual command tools (such as tapi) from the current Xcode. I figured that if I was unable to generate equivalent files, I must be doing something wrong. So, I'm happy to hear that the lack of UUIDs in the .tbd is not a problem. Now, you may be thinking that I should not need a JNF framework that runs on 10.10, as 10.10 already has a JNF. That seems reasonable, assuming that the dynamic linker ignores frameworks on the path that don't support the current OS and arch. However, someday I may wish to replace JNF with my own, much smaller framework, and I want that framework to run on 10.10 and later. So, my questions are: Do I need a .tbd file in a framework to run on some releases of macOS? If so, which version of the .tbd file should I use for maximum compatibility with older macOS release? Thank you for your assistance!

The cluprit turns out to be Finder! Yes, if a directory is nested below a directory that is displayed by Finder with the Calculate All Sizes view option enabled, Finder will cache the directory cumulative size in a .DS_Store file in that directory and will update the cached size in response to FSEvents. The upshot: if a user uses the Calculate All Sizes option, standard Unix commands such as /bin/rm -rf may fail intermittently.

FB10023961

Deleting a file (any file) may generate an FSEvent that triggers a background process to examine the directory or directory tree. If the background process somehow creates .DS_Store files, that would explain the behavior. Spotlight indexing and Time Machine backup come to mind as possible culprits.

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]