> This seems to be described in
https://eclecticlight.co/2024/04/29/apfs-beyond-to-vfs-and-v... but I'm just a layman here. I don't quite understand the benefits of this caching if you have to recompute them to detect mismatch anyway.
It appears that Howard Oakley is once again very confused. Unfortunately, his blog is sometimes a foundation of misinformation, which drives me nuts. The Apple technical note that he links to is talking about a process updating itself at runtime while its code signing information is cached by the kernel in memory. Oakley has somehow warped that into a some kind of disk cache, using the odd phrasing "saved to the kernel's cache against the vnode".
> spctl has a --ignore-cache option. So the result of gatekeeper is indeed cached somehow.
Yes. I think it's in /var/db? But again, it's not a cache of the hashes of every file in the app bundle. What would the system even do with that? Not only is there no evidence for the existence of such a thing, but its existence would make no practical sense. Oakley is simply grasping for something that takes a significant amount of time computationally, without giving much consideration to what would be done with the products of that computation.
> And presumably as you noted it's a cache miss for this which causes the long application launch delay.
No, I've showed that it's a periodic malware scan.
It appears that Howard Oakley is once again very confused. Unfortunately, his blog is sometimes a foundation of misinformation, which drives me nuts. The Apple technical note that he links to is talking about a process updating itself at runtime while its code signing information is cached by the kernel in memory. Oakley has somehow warped that into a some kind of disk cache, using the odd phrasing "saved to the kernel's cache against the vnode".
> spctl has a --ignore-cache option. So the result of gatekeeper is indeed cached somehow.
Yes. I think it's in /var/db? But again, it's not a cache of the hashes of every file in the app bundle. What would the system even do with that? Not only is there no evidence for the existence of such a thing, but its existence would make no practical sense. Oakley is simply grasping for something that takes a significant amount of time computationally, without giving much consideration to what would be done with the products of that computation.
> And presumably as you noted it's a cache miss for this which causes the long application launch delay.
No, I've showed that it's a periodic malware scan.