Thanks, I ended up finding a solution myself... it appears I was misunderstanding the way the static keyword works in Swift. Here's what I ended up with (minus error checking that would go into the real code, of course): class foo {     static var a: String?     func printit() {         print(foo.a)     } } class bar: foo { } foo.a = "def" let someBar = bar() someBar.printit() This does what I want. Your point about being cautious with these things is taken; not to worry, this isn't something I plan to do much of, but it does provide a cleaner solution to tie this to the class rather than making it a true global. 🙂

Is this what you look for ? Not quite, no... I want to be able to set the value from outside, not from within one of the child classes. Here's one of the examples I tried out in a playground, which actually "crashed" with an EXC_BAD_ACCESS error. 😬 The basic idea is that it's an object that will be available to all subclasses, but that is not known at compile time and must be set at runtime. I'm trying to avoid the use of a global variable, as that's a poor solution, but I'm starting to wonder if Swift supports the concept of these class variables in the same way that other languages I've used do. class foo {     class var a: String {         set { self.a = newValue }         get { return self.a }     } } class bar: foo {     func printit() {         print(foo.a)     } } foo.a = "abc" let someBar = bar() someBar.printit()

Okay, thanks. Entitlements may be on the nose, as I'm seeing weird behavior when trying to run ditto from within Swift, as opposed to in the Terminal. I wanted to do a quick comparison, and running ditto via this code, in a Swift Playground, didn't work: import Foundation let srcPath = "/Users/thomas/Desktop/test.txt" let destFolderPath = "/Users/thomas/Desktop/test-folder/" func util_shell(_ command: String) - String {     let task = Process()     task.launchPath = "/bin/bash"     task.arguments = ["-c", command]     let pipe = Pipe()     task.standardOutput = pipe     task.launch()     let data = pipe.fileHandleForReading.readDataToEndOfFile()     let output: String = NSString(data: data, encoding: String.Encoding.utf8.rawValue)! as String     return output.trimmingCharacters(in: .whitespacesAndNewlines) } let theCommand = "ditto -v \(srcPath) \(destFolderPath)" print(theCommand) let theOutput = util_shell(theCommand) print(theOutput) This resulted in the following output: ditto -v /Users/thomas/Desktop/test.txt /Users/thomas/Desktop/test-folder/ Copying /Users/thomas/Desktop/test.txt  ditto: /Users/thomas/Desktop/test-folder/.BC.T_hHCsH6: Operation not permitted Of course, maybe this isn't about entitlements and just means I screwed up the util_shell function somehow. It works for other shell commands, though. I'm guessing I'll probably need to write more complex code, that captures important metadata about the source file(s) and writes that out to the destination. Sounds like a big job, though. I shudder at the thought of recursing through an entire folder tree and accurately copying everything inside... Thanks for your suggestions!

Hmmm, and you’re not using asr? Not for this purpose. I'm just capturing specific files, not imaging the entire disk.

Also, I didn't directly answer this question: What practical problems do you see with the attributes you get when copying with FileManager? In the example I cited above, both the UUID (for looking up the entry in the QuarantineEvents database) and downloading agent are missing, and the quarantine value and timestamp have been changed.

What I'm working on is for file collection for forensic purposes, so being able to see things like a quarantine attribute, accurate timestamps, ownership info, etc, can give important information. Even capturing resource "forks" can be important, as some threats these days are known to hide malicious code there, where most security software won't find it.

We're seeing exactly the same issue at Malwarebytes. Specifically, we're seeing some customers where: kext activation fails /private/var/db/KernelExtensionManagement is missing the restricted flag Adding the restricted flag to the folder from recovery mode fixes the issue We have seen this happening for users on High Sierra and Mojave. We have no idea at this point if it also affects Catalina, as we don't use a kext on Catalina anymore, and haven't for months. On affected systems, the results of kextutil -tn /Library/Application\ Support/Malwarebytes/MBAM/Kext/MB_MBAM_Protection.kext 2>&1 are as follows: Error making temporary directory: 1 Memory allocation failure. Unable to stage kext (/Library/Application Support/Malwarebytes/MBAM/Kext/MB_MBAM_Protection.kext) to secure location. Our kext is notarized, and the affected users all have SIP enabled. I've filed a bug report (FB8812838).