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 #27
2. 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.

[lrasmus]

Thank you! Just wanted to rule it in/out as a factor.

[lrasmus]

I've been back through this a few times, and glad I did because I missed a few details and learned a few new things.

First, I think the error you're seeing from the log file is caused if you are selecting the directory to store the log file, instead of an existing file. This is going to be fixed (see #42).

It was interesting to me that you're still able to see Word documents in the document list in StatTag. I realized I missed in your original post this error:

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

This appears to be an error coming from some of our AppleScript code that interops with Word. So some of the AppleScript is working (otherwise you wouldn't see the list of documents), but this is not.

I'm wondering if you would be able to share the specific version of Word you're using (I'm on 16.54 (21101001)). Unlikely to be caused by a Word update, but as always I just want to rule it out and make sure I'm able to replicate the problem on my end. Thanks!

[ewhitley]

Sorry quick follow-up questions as well re: Word.

1. Mac App Store version or stand-alone installer from Microsoft?
2. Office 365 or single purchase/non-subscription?

Apologies for brevity. On phone.

[mronkko]

I am running Office for Mac 16.53 (21091200)

1. Neither. This is installed with Managed Software Center. I guess it is closer to stand-alone.
2. Office 365.

[mronkko]

I was able to get logging to work by creating an empty log file. However, no entries are added to the log file when I try to add files to the project. The log level is set to verbose (Level 1).

[lrasmus]

@mronkko - we were able to address the issues with log files being created, and added some additional logging when linking code files. Would you be able to try out the latest beta (3.0.7-beta5) when you have some time? I'm hoping that the logging will work now, and we'll get some additional information about why the code file linking isn't working. Thanks!

[mronkko]

It seems to work now. I did not test it very extensively, but I was able to run updating tags without any problems. Thanks.

[lrasmus]

Thank you for the quick test! We'll keep testing here too.