And how do I get it back?
I wanted to test the helper app of my main app on wonderful wonderful Catalina. The helper is basically a timer which starts the main app. It has a LaunchAgent which makes sure that the app is restarted when macOS is restarted. After restarting I got an error message about a Runtime error which was related to a mutex not finding the temp folder. I restarted the computer again. Then I got the error every 10 seconds. Xojo had the same error but started fine. Feedback also has the same error and now doesn’t want to start at all.
I did a simple test with
dim f as FolderItem = SpecialFolder.Temporary
f = GetTemporaryFolderItem
and both give back nil. Doing a
in Terminal gives back
which is empty. How did I do this and how do I fix it?
Don’t know about the folderitem issue…
but confused about your statement in relation to the terminal command…
you indicated it gives back a temp file, but it is empty.
Why would it have any contents?
and I think $TMPDIR gets a new value each session, with the previous contents deleted during shutdown
@Beatrix Willius SpecialFolder.Temporary and GetTemporaryFolderItem are still using Carbon calls, I guess, and they require a TemporaryItems folder to be created within $TMPDIR.
Maybe Catalina no longer supports it or Carbon calls are trying to use FSRef.
@Dave S : the Terminal command should give the location of the temporary folder. The temporary folder always has some files in there.
@Stéphane Mons: I have been running Catalina from day one. Lots of problems, but the temp folder worked fine. I only did the testing with the helper app today.
Disk First Aid told me that I borked something. I’m doing a backup right now and then I’ll try to let Disk First Aid fix the problems.
Running Disk First Aid didn’t fix anything. So I guess it time to reinstall Catalina.
@Beatrix Willius Have you tried reverting to a previous snapshot? If APFS is slow, at least it has some advantages
The way I see it that there are multiple points of failure here.
- Could be that the API Xojo uses is deprecated/broken on Catalina. You can try this declare to get the path, it’s not marked as deprecated, but that doesn’t mean it isn’t or that it works.
declare Function NSTemporaryDirectory Lib "Foundation" as CFStringRef
If this only occurs in the Helper application, I would ask how the Helper application is code signed. Is it Sandboxed? If so, are both the helper and main application Sanboxed?
If they are Sandboxed, then IIRC you need to use a Group Container. Both apps need to have the container id specified in their entitlements (See Group Containers in the Capabilities section of App Wrapper). Then you must use code similar to below to access that container. The group container ID is your code signing team ID plus an extension, i.e. “QXAFMEPH9Y.shrd”.
[code]Public Function groupContainer(identifier as string) as folderitem
#if targetMacOS then
// — This code requires OS X 10.8 or newer.
declare function containerURLForSecurityApplicationGroupIdentifier lib "Foundation" _
selector "containerURLForSecurityApplicationGroupIdentifier:" ( NSFileManager as integer, groupIdentifier as CFStringRef ) as integer
Dim groupContainerURL as integer = containerURLForSecurityApplicationGroupIdentifier( NSFileManagerDefaultManager, identifier )
if groupContainerURL = 0 then
oak2017.DebugLog currentMethodName + " error: Group container ID is invalid """ + identifier + """."
declare function checkResourceIsReachableAndReturnError lib "Foundation" _
selector "checkResourceIsReachableAndReturnError:" ( NSURL as integer, byRef error as integer ) as boolean
Dim theError as integer
if not checkResourceIsReachableAndReturnError( groupContainerURL, theError ) then
declare function createDirectoryAtURL lib "Foundation" _
selector "createDirectoryAtURL:withIntermediateDirectories:attributes:error:" _
( NSFileManager as integer, NSURLInstance as integer, ci as boolean, atts as Ptr, byRef error as integer ) as Boolean
if not createDirectoryAtURL( NSFileManagerDefaultManager, groupContainerURL, True, nil, theError ) then
declare function localizedDescription lib "Foundation" selector "localizedDescription" ( NSErrorInstance as integer ) as CFStringRef
oak2017.DebugLog currentmethodName + " error: " + localizedDescription( theError )
declare function absoluteString lib "Foundation" selector "absoluteString" ( NSURlRef as integer ) as CFStringRef
return getFolderItem( absoluteString( groupContainerURL ), folderItem.pathTypeURL )
@Sam Rowlands :
- Xojo was working fine before testing the helper app. I changed the path to the app in the Launch agent to
because Applications wouldn’t work anymore.
- The Helper app, Xojo and Feedback are affected. I can’t use Xojo much because my main app crashes now when starting. Xojo isn’t signed on Catalina.
Oh, fudge, I just read that the there is now some sort of pre-public beta. Does this mean that Xojo now can look at the Catalina problems?
Clearly a problem, but could you shell $TMPDIR at the start of the app , and use that to get a folderitem for your own custom
What we said was that you shouldn’t be discussing unreleased versions of macOS publicly until Apple lifts that restriction and we were expecting that to happen when there was a public beta. That said, I’ve just been to Apple’s website and I see no indication that a public beta announcement has been made.
As far as when we will start reviewing cases, we typically wait until Developer Beta 3 or Beta 4 and at the rate they are moving, I’d expect it to be the latter at the earliest as there are (as you must know) still some basic system features that are not working correctly in of themselves. Just for reference, last year it was mid-July when things settled down on Apple’s end and I see no indication that it is going to be any earlier this year.
To be clear, from what I’m reading it appears that Apple is slowly rolling this “public beta” out across the globe, that it is only a few builds newer than Developer Beta 2 and that many of the early adopters who are using it so far are telling others to stay away because it is highly unstable.
@Greg O’Lone : Bugs don’t fix themselves. Are you going to tell your users “oh, we want you to use beta-test Xojo only after the third or fourth beta”?
I understand where you come from. It’s way too much work to have a look at each and every bug from Catalina as long as we don’t know where Apple is going. However, as far as I can see they changed ALL file access. A good part of my app doesn’t work anymore. I need at least to identify what isn’t working and I need to be sure which parts I need to change.
We would not, but it wouldnt be out of line for you to say to your customers that you would not be fixing certain bugs in your software until the current pre-release if Xojo had gotten stable enough if there were some new feature you needed for your next release. We strive to release very stable Betas… we dont always succeed, mind you, but we do try.
All Im saying is that with all of the issues it has, this new version of macOS so far is more like what we call an early Alpha than our idea of a feature complete Beta. Things are still wildly changing, networking is still broken in many ways (my test system takes two or three reboots to get one that will connect to the internet), and yes, theyre making changes to the file system again.
Please dont take out lack of motion on user reports as if were not looking and watching very carefully. We have a fair number of internal unit tests with a fair amount of coverage of FolderItem which well need to get working before we even start tackling user submitted issues.
Its more about not wanting to fix things more than once if we can help it. Thats why were letting their betas settle down. Just about every time we jump on a change right away, we get bitten because Apple changes their mind again after they get pushback from the community. A great example of this is Drag & Drop. Something changed in 10.14 which caused some peoples IDEs to crash when dragging multiple items and others to just refuse to initiate the drag. We spent a fair amount of time trying to figure that out and then Apple reverted the change in 10.14.5 and everything works again.
Keep in mind that were in the same boat in many ways. Because the Xojo IDE is written in Xojo and each release is built on the same frameworks that are in the release, we must be sure that all of this is working even before we can ship an alpha to our internal testers, because without it, the IDE may not build.
I apologize if I come across as flippant about this at times, but just like last year (and the years before) were in that tight spot where a lot of users want to start playing with the newest macOS release to see if their apps work and when they dont, they start filing bug reports (our customers and yours) some of which we cant tell if theyre our bugs or Apples bugs yet.
We do hear all of you and we know that its important to everyone that we support this new OS. Unfortunately we just dont have anything tangible to give you quite yet. But were working on it.
Uff, I’m back in business on my laptop.
@Stphane Mons: totally cool idea with a suboptimal interface. Unfortunately, I didn’t have any saved snapshot.
@GregO’Lone : I understand what you are saying. I don’t expect Xojo to fix any problem tomorrow. We still need to be able to discuss problems because Catalina changes so much.
And now I’ll install Catalina on a VM for further testing.
Just to confirm that my app too, compiled with Xojo 2019r1.1, crashes on Mutex constructor likely due to the nil tempfolder item on Catalina.
@Stephen Dodd: sugar, I had really hoped that this was somehow just me. I made a Feedback case (56167) which is private. However, everything is now back to working. I can open Xojo, my app and Feedback.
Do you remember what you did before your crash happened?
As a workaround, you could test Temp folder for nil, and if so, create your own. It will mean using a mechanism to avoid duplicates and collisions, but a simple naming based on microseconds, or on date.totalseconds, should be enough.
Of course, stuff like Mutex will remain impaired.
It seems to be pretty consistent that using Mutex crashes the app. Haven’t tested it myself yet. Just reports from my users.
@Michel Bujardet : even if I could make Xojo work Valentina crashed, too, as it seems to use a Mutex, too. Replacing the Mutex myself doesn’t seem too much work, that is correct.
Apples public beta site isnt responding properly but there are numerous public sites like 9to5, mac rumors, sixcolors etc all reporting that the public beta has been posted
EDIT : Apple Betas is up and you can sign in
But its not fast at the moment