GetTemporaryFolderItem and Catalina

While running through the debugger on 10.15 i can call GetTemporaryFolderItem() and see that the isReadable and isWriteable flags are true.
I can actually write to the file and then read in the contents to validate this.
I then send a request to Photoshop to write out some data into that temp file and it then the flags isReadable and isWriteable change to false.
Trying to open the files results in nil object exceptions.

Is there some issue with Photoshop writing to that file that causes it to become unaccessible?

Didnt Adobe issue some statement about their apps, issues, and updating to Catalina ?
https://helpx.adobe.com/photoshop/kb/photoshop-and-macos-catalina.html

there are issues
https://www.creativebloq.com/news/adobe-catalina-issues

I had to refactor an app of mine which was using Temporaryfolder as scratchpad.

I ended up using a Temp folder inside specialfolder.ApplicationData

I’ve been looking further into the issues we have been having with the temporary folder on Catalina.

It appears that the temporary folder returned by SpecialFolder.Temporary on Xojo <2019r2 is different to the folder returned by Xojo 2019r2. The Xojo <2019r2 temporary folder seems to be a subfolder of the one returned by Xojo 2019r2.

I hacked our application built with Xojo 2017r3 to use the same temporary folder as Xojo 2019r2 and the problems seemed to disappear.

It looks like the macOS API FSFindFolder is either returning the wrong path or the path is correct and it’s permissions are wrong.

I have updated our open case with Apple with this information in the hope that they fix it.

For now, we have implemented the same solution as Michel. I think MBS has a function to return the temporary folder which might also work.

[quote=457729:@Graham Busch]While running through the debugger on 10.15 i can call GetTemporaryFolderItem() and see that the isReadable and isWriteable flags are true.
I can actually write to the file and then read in the contents to validate this.
I then send a request to Photoshop to write out some data into that temp file and it then the flags isReadable and isWriteable change to false.
Trying to open the files results in nil object exceptions.

Is there some issue with Photoshop writing to that file that causes it to become unaccessible?[/quote]
This is basically one of the problems we had. Application ‘a’ couldn’t access temp files created by application ‘b’. We noticed that if both apps had the same bundle ID the problem went away. See my other post re> the temp folder path.

It looks like you cannot share temporary files between apps. So I am guessing Photoshop writing to that temp file stops my app from being able to read it it, I am actually deleting the temp file before asking photoshop to run.

Steps are

  1. Get temp folder item (it exists and you can read and write)
  2. Delete the temp file (you can write only now)
  3. Ask external app to create that file
  4. You cannot read or write to the file

If you need to do this for transmitting data use Michel’s applicationData solution.

[quote=457742:@Graham Busch]It looks like you cannot share temporary files between apps. So I am guessing Photoshop writing to that temp file stops my app from being able to read it it, I am actually deleting the temp file before asking photoshop to run.

Steps are

  1. Get temp folder item (it exists and you can read and write)
  2. Delete the temp file (you can write only now)
  3. Ask external app to create that file
  4. You cannot read or write to the file

If you need to do this for transmitting data use Michel’s applicationData solution.[/quote]
If you have the MBS plugins maybe try: NSFileManagerMBS.temporaryDirectory

There is also a Group Container function, which can be shared between apps (Sandboxed and unsandboxed).

Actually, the folder returned by SpecialFolder.Temporary is identical to what you get in terminal with

echo $TMPDIR

Which means it is the system temp.

Catalina must have added some extra security, or something.

[quote=457846:@Michel Bujardet]Actually, the folder returned by SpecialFolder.Temporary is identical to what you get in terminal with

echo $TMPDIR

Which means it is the system temp.

Catalina must have added some extra security, or something.[/quote]
We see the following:
• Xojo 2017r3
/private/var/folders/5s/713x7fh50qz5_w4fdkt1xdf80000gn/T/TemporaryItems

• Xojo 2019r2
/var/folders/5s/713x7fh50qz5_w4fdkt1xdf80000gn/T

I’m pretty sure that $TMPDIR is the same as Xojo 2019r2.

As a test, I rebuilt our app using Xojo 2017r3 to use the path reported by Xojo 2019r2. Basic testing indicated that the problems were solved.

so… Either the TemporaryItems subfolder has the wrong permissions or the FSFindFolder API that the Xojo Framework was using is returning the wrong path.

What is interesting is that if I use Terminal I cannot list the content or manipulate anything in the TemporaryItems subfolder.

[quote=457874:@Kevin Gale]We see the following:
• Xojo 2017r3
/private/var/folders/5s/713x7fh50qz5_w4fdkt1xdf80000gn/T/TemporaryItems
[/quote]
Old FSspec based API

New NSURL (I think) based API
EDIT : although they could be asking NSFileManager for these

so its not a surprise they return different locations

I would be inclined to consider the path reported by $TMPDIR as well as 2019R2 as the right one.

Under Mojave, SpecialFolder.Temporary is always writable, and i’s native path is identical to $TMPDIR.

Now, why that path sometimes reports isWritable as false under Catalina is the crux of the mystery. I am convinced Apple invented yet another hoop to jump. With some luck, it should be solved in 2019R2.1 :wink:

On older versions of the macOS; /var/ is a symlink to private/var/, I can’t check on Catalina right at this moment, but I guess they changed that.

I’m pretty sure it still is.
The issue seems to be with the TemporaryItems subfolder that is included by the older API. We cannot access it via Terminal, we sometimes see Sandbox violation errors when accessing files within it (our apps aren’t Sandboxed) and we see some crazy read/access issues if we copy a file that has extended attributes into the folder and then try to use it.