Why You Can’t Save a logarchive There
I think the problem is that my app is running an AppleScript, which is running a shell script, which in turn actually needs to be entitled to write to this removable storage. Although the user selects the location in which to save the logarchive – which surely establishes user intent, Apple’s reason for permitting the action – that intent isn’t communicated through the AppleScript and shell script chain to give the
logcommand the ability to save the logarchive where the user wants.
Previously:
Update (2020-01-06): Howard Oakley:
It’s this which is most frustrating of all, that neither the user nor developer gets to know, let alone grok, the rules, nor do they appear able to modify them so that macOS works the way that they expect it to. Controls in the Privacy tab don’t appear to apply to per-file privacy protection accomplished using the
com.apple.maclextended attribute, and as the extended attribute itself is protected by SIP, neither user nor developer can remove or modify it. There’s no override feature, no off switch, and no way to get your Catalina Mac to forget about per-document privacy protection and its bizarre behaviours. When you’re trapped with a document that’s behaving like a crazed cat, there’s just nowhere to go.[…]
If this is how per-document and folder privacy is going to work, then it turns using files in macOS into a game of chance, and it’s a chance that is only going to deter users. When privacy protection has these unpredictable and obstructive effects, it’s surely time to consider whether it isn’t bringing the whole of macOS, and by association Macs, into disrepute.
