StatTag 3.0.7-beta4 does not work on MacOS 10.15.7, file permission problem?

[mronkko]

I am using StatTag 3.0.7-beta4 on MacOS 10.15.7. StatTag does not work at all. I suspect that this is some kind of permission problem related to sandboxing. StatTag never asks for any file system permissions. Giving it full file system access did not work.

Here are the symptoms:

1. When I try to open a log file, I get "The debug file you have selected appears to be invalid, or you do not have rights to access it. Please select a valid path for the debug file, or disable debugging."
2. When I try to open a code file, no files appear on the "code files list".

Because I cannot open any code files, StatTag of course does not work at all.

When I run StatTag from Terminal, I get the following error message in the terminal when trying to open a code file:

"2021-10-11 20:53:31.084 StatTag[19927:565033] *** -[WordASOC createOrUpdateDocumentVariableWithName:andValue:]: Can’t get name of missing value. (error -1728)"

This is repeated every time I try to open a file.

[mronkko]

The same problem occurs on my work Mac runnig MacOS 11.6 .

[lrasmus]

Thank you for reporting @mronkko! And as always, sorry for the issues... Appreciate knowing this is an issue on both macOS 10.x and 11.x

@ewhitley - any idea why StatTag wouldn't ask for permissions (what could cause that)?

[lrasmus]

@mronkko - even though StatTag didn't prompt you for permissions, I'm wondering if it is showing up in your Privacy & Security settings. I was able to replicate this by going in and disabling StatTag's Automation access. When I checked the boxes to re-enable this, things started working. Would you be able to look and confirm if you see StatTag listed, and if the boxes are unchecked or checked for Word (you may not see Stata)?

[mronkko]

Yes it does, though only for Word. StatTag did not ask for file permissions, but I manually gave it full disc access. This does not help, but I still get the error "The debug file you have selected appears to be invalid, or you do not have rights to access it. Please select a valid path for the debug file, or disable debugging." and cannot add analysis files to the project. The integration with word works and StatTag shows the tags in the Word document.

.

[lrasmus]

Thank you! I misunderstood what you were seeing and what you had already tried, sorry. Thanks so much for the clarification!

I wanted to ask, for the log file - I forgot that in StatTag for macOS we do not create the log file for you (like we do on Windows). I was curious if you have a file named StatTag.log in the directory your selecting for the log file (realizing per #2 there are still some other log issues going on). If not, that may explain the error message you're seeing specifically for the log file.

[ewhitley]

Re: automation permissions - we currently have two related open issues on that one and a Radar bug open with Apple. It's a known issue, but Apple has not responded at all on a solution.

For now we have no option but to continue disabling the script access permissions check.

When we have it enabled, the behavior with Stata is extremely unpredictable and tends to hang everything. Theory on the discussion lists is it has to do with how Stata is updating their app, which impacts the signature and hangs the privacy check. Until that's resolved, we're stuck in that check. Plus, it's an OS thing, so it's tough to know who has what patches applied once it is fixed (if ever).

Updating with issue references to Stata permissions issues:

1. StatTag unable to bring up Stata when closed StatTag unable to bring up Stata when closed #27
2. AEDeterminePermissionToAutomateTarget fails to respond AEDeterminePermissionToAutomateTarget fails to respond #31

[mronkko]

Thank you! I misunderstood what you were seeing and what you had already tried, sorry. Thanks so much for the clarification!

I wanted to ask, for the log file - I forgot that in StatTag for macOS we do not create the log file for you (like we do on Windows). I was curious if you have a file named StatTag.log in the directory your selecting for the log file (realizing per #2 there are still some other log issues going on). If not, that may explain the error message you're seeing specifically for the log file.

There is no log file in /Users/mronkko/Documents, which is the default folder.

[ewhitley]

This previously worked, so we need to look at what's happening with security authorization. It's likely that after we set up the hardened runtime to get it to work on 10.15+ we kept the default directory to users/{user}/Documents, which is secured by default.

1. We should have the ability to write to a specific local app-specific directory (I need to check docs) by default
2. Then if the user changes the path, the OS security system should prompt for approval and authorize.
3. I think there's an API to also check permission to the file/folder, which we should also do prior to attempting the session file write or doing anything with that dialog box

[mronkko]

Yes. What makes this weird is that StatTag does not work even if I give it full disk access. I was going to install Xcode and build it locally to see what the problem is, but my home computer is so old that Xcode does not install and the work computer is so full of datasets etc that there is no hard disk space.

[ewhitley]

Determining Where to Store Your App-Specific Files
https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/AccessingFilesandDirectories.html#//apple_ref/doc/uid/TP40010672-CH3-SW11

More on prompting for access and persistent security. It's in Swift, but the APIs should be the same. The section on persistent access is key here.
https://benscheirman.com/2019/10/troubleshooting-appkit-file-permissions/

[ewhitley]

I also noted the human-readable path looks different recently for some reason in the UI. Under the hood it's (supposed to be) a filesystem version of NSURL, but previously the UI didn't show "file://" - which I get, but... that's different. It's possible there's something else goofy going on like we're properly managing the URL type.

[lrasmus]

@ewhitley - for log path, please see #2. I have a fix proposed for that.

[lrasmus]

@mronkko - we had another thought come up. When you are trying to access a code file, where is the code file located (and where is the Word file located)? Is this all local on your device, is it a network folder, external drive? Thanks!

[mronkko]

@lrasmus All local.