#CHRONOSYNC RESOLVE ALIASES PDF#
#CHRONOSYNC RESOLVE ALIASES UPDATE#

I happened to read an article by Shane on a related matter, and it occurred to me that there’s another workaround to consider. Can the vanilla AS script call a separate ASObjC script without making the main script ASObjC? I’m assuming, if this is possible, that it would have to “run” the script, not “load” it. I have lots of scripts bundled that the main script of the applet calls, but all of them are vanilla AppleScript. Abandon hope all you who enter here.'īut maybe I could put this logic in a handler within a separate ASObjC script file, called by the main script? It is also a hallmark of the per-file privacy protection system at work. Its purpose appears to be to maintain document access when files are moved between protected and unprotected folders: it seems to act as a whitelist which ensures that, no matter where that document goes, approved apps will continue to be able to access it. This xattr contains one or more UUIDs which are associated (somewhere) with (non-sandboxed) apps. 'The xattr which is associated with Catalina’s protected folders is, which is usually (but not always) protected by SIP, so you can’t remove it from the document or folder, which is a real pain. I wouldn’t be surprised if this has something to do with the files ‘’ extended attribute I haven’t yet tried testing to see if there is some kind of ‘timeout’ associated with whatever flag is set after a file has been opened or if that flag survives a restart of the Finder or even host machine. I have noticed that running the above script without the shell script open command, even though the Finder will not open files not recently opened, the script does however set the ‘Last Opened’ value in the Finder window listing to the time at which the Finder open command failed. I assume that opening the file in this way sets some kind of flag. If the file has been previously opened recently, either manually by double clicking on it etc or by using the shell script Open command, then the Finder script will open it. Running the above test script I have discovered…

#CHRONOSYNC RESOLVE ALIASES UPDATE#

I can confirm that the problem still seems to exists after the 12.3.1 update on my machine (Mac mini 2018) do shell script 'open ' & quoted form of thisPOSIXfile Set thisPOSIXfile to POSIX path of (thisFile as alias) Set theFiles to every file of (path to documents folder) whose name extension is 'pdf' I modified all of my scripts affected by this bug to use ASObjC to open files (as suggested by Shane), everything works fine. The first attempt to open the file returns the error message a second attempt often successfully opens the file. I mentioned above that this issue was intermittant, and a controlling factor seems to be whether an attempt was made to open the file recently. It makes no difference if the script is run from Script Debugger, Script Editor, or as an app on the desktop.

The document “New Text File 1.txt” could not be opened.

#CHRONOSYNC RESOLVE ALIASES PDF#

It doesn’t seem to matter if I use alias or file specifiers, and the PDF document itself doesn’t appear to make a difference.

The file “AppleScript Objective C.pdf” couldn’t be opened because you don’t have permission to view it. I upgraded to 12.3.1 and, when using the Finder to open a PDF, I now get intermittent error messages like:

Chronosync resolve aliases