Post not yet marked as solved
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?
Post not yet marked as solved
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!
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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!
Post not yet marked as solved
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.
Post not yet marked as solved
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
Post not yet marked as solved
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!
Post not yet marked as solved
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]
Post not yet marked as solved
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
Post not yet marked as solved
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.
Post not yet marked as solved
Calling validateVisibleColumns appears to fix the problem.
Post not yet marked as solved
sudo /usr/libexec/configureLocalKDC
did not work for me
Post not yet marked as solved
I am encountering a similar problem. I believe that the panel is not treating your first filter specially, but rather it is caching the results returned by shouldEnableURL to avoid making multiple calls for the same URL. Sounds like a good idea, except for delegates that change their behavior as yours does. How clever of Apple to introduce this incompatible change without documenting it or providing a way to flush the cache.
