Update: Headline for this post is changed from ”Turn off Catalina’s Privacy Protection Policies?" to pointing out the problem itself. I’m not sure turning off Privacy protection is the solution, so I don’t want to rule out other suggestions.
In any case, SystemPolicyNetworkVolumes has nothing to do with it. So my just question below are no longer relevant – but the problem description is. ------------
Is there any way to turn off Catalina-s new Privacy Protection Policies regarding file locations, specifically SystemPolicyNetworkVolumes?
The reason for this need is that running scripts for InDesignServer have become unacceptably slow for us after upgrading when the process evolve interactions with files on file servers (SMB).
As an example, one such script took just above 1 minute to run a capably small task under Mojave (varying between 1:01 and 1:10). After upgrading to Catalina they take at best 3m 30s, but sometimes more than 5 seconds. So there is also more variation now, but even the best scores means more than tripling of processing time compared to before e – which is totally unacceptable in the production context.
After a lot of analyzing and testing, we have concluded this must be connected to the new system policies in Catalina. The suffering scripts works a lot with files on file servers, e.g. images. My theory is that for every Indesign action that involves files in a "restricted area”, like a file server, macOS have to check if the process have access to those files. One such check might take a a few milliseconds – but Indesign seems to continuously retieve data from all linked objects, not just once. So those milliseconds might sum up to minutes.
I’m quite convinced performance would be normal again if we could totally turn off SystemPolicyNetworkVolumes (and maybe its fiends too) – but is that even possible?
I believe turning off SIP alone will not do the trick.
I don’t have an answer to your direct question. I would, however, question whether it’s just a network volumes issue. It may well be — but I wouldn’t be surprised if it’s not quite that simple.
You were right in questioning my conclusion @ShaneStanley. Tweaking the test script to be independent of network volumes made no difference. (The reason to the higher difference in process time before and after Catalina upgrade compared to other scripts might be traced to the more intense interaction with the Indesign documents)
But I still suspect the new Catalina security measures to be involved. This observation does not indicate a solution, but looks like a lead:
As part of the investigation, I disabled SIP and followed the other hacks in this article to deactivate some of Catalinas security measures.
After that, running my example script via soap calls or directly from ScriptDebugger made no clear difference in process time. (Since the scores differs so much between different executions of the same script after after the Catalina update I cannot say there are no difference att all, but if so it is small)
However, with Apples Script Editor the script run much faster, almost as it did with any execution method before the Catalina update. And process times are stable, not varying abnormally much between executions.
Before doing the hacks, execution from Script Debugger and Script Editor performed equally (bad) in average, varying greatly within the same variation span. From soap calls even worse.
I don’t now what further conclusions to make from this or how to move further. But it seems to verify that our performance problems has something to do with Catalinas new security measures.
Hi, Havard.
Under normal circumstances the scripts are executed by soap calls as common with InDesign Server solutions. ScriptDebugger and ScriptEditor are sometimes used for testing, and in this case also for comparison.
So they are saved as scripts (and no code signing have to be involved).
With soap calls, “IndesignServer” always owns the script process.
One thing I’d add is that I don’t think you can change how an app behaves in terms of App Nap using defaults — it’s initiated by the system. From the docs:
By default, your app becomes eligible for App Nap if it’s not actively engaged with the user and hasn’t updated a visible window for some length of time.
That sounds potentially problematic for a faceless app like InDesign Server, and probably explains what you’re seeing. And:
You can also help the system determine when to put your app in App Nap by distinguishing between important user-initiated activities and your app’s discretionary or asynchronous activities. When your app communicates that it’s performing discretionary activities, the system efficiently puts your app in App Nap. When your app tells the system the user has initiated a long-running operation that the user expects to complete “now,” the system does not put your app in App Nap.
It sounds like Adobe aren’t setting an activity options to do this.
Anyway, now that you’ve worked out the problem, the solution from your end is pretty trivial: just keep activating every so often.
Actually it seems there only have to be one activate, just in the beginning of the (main) script. I haven’t been able to slow down the script processes, even long lasting ones (like 15 minutes), by bringing other visible processes to the front.
But if I’ll be proven wrong further on, I know what to to.