Strange File Path

Hello

A client did report a problem on High Sierra with a program we made in Xojo. Following Code is not working on his Mac:

app_path=GetFolderItem("")
LoaderFile1=app_path.Child(LoaderFilePath1)
read_stream=LoaderFile1 .OpenAsBinaryFile(true)   // ??????

if read_stream=Nil then     
  MsgBox("Error: " + LoaderFile1.AbsolutePath )
  return False  
end if

The Error returned is: “Error: A299437A-F8CF-43DC-878E-64A8E1A8810B:d:FootControllerLoader.img”
The folder of the build application is inside the “Application” folder of the Mac, and the “FootControllerLoader.img” we try to open is inside the same folder as the application.

Can someone tell me where this strange file path comes from?

Thanx
Lukas

Your app is probably being sandboxed by the OS. Which means you don’t have permissions to create a file in that location.

The os will do shadow sandboxing for freshly downloaded apps. Move the app to the Applications folder and it should be fine.

If it is a read only file, put it in the bundle Resources folder.

But he’s reading a file, not writing it.

But he already said the app IS located in the Applications folder.

I second that recommendation.

Also avoid putting your app in a folder and then putting that folder in the Applications folder. Many apps work this way (Xojo for example) but the behaviour is getting weirder because the OS is moving things around, shadowing files in sandboxed Containers, which leads to these kinds of nightmares for developers.

Now and then lovely macOS decides that an app isn’t kosher and does the “app translocation” thing even though it shouldn’t. There have been reports that even Xojo does this (“Xojo doesn’t load my plugins”). Even when the app has been signed, the dmg has been signed and the app has been moved around.

On startup an app need to check it’s own path to see if it’s in translocation mode and give the user a warning.

And yes, the file either should be in documents or inside of the app.

Or let it copy to Specialfolder.ApplicationData before using it.

Is there a way to detect translocation path?

Yes. Precisely GetFolderItem(“”) path won’t contain /Applications

Or App.ExecutableFile, check if the path contains /Applications.

True indicates writable. Try passing False.

Thanx for all the replies. Unfortunately, the problem is still not solved. This issue is only on High Sierra; on older OS it works fine. The problem is already in “app_path=GetFolderItem(”“)”. This does not get the correct path.

What should I do instead?

How do I this and how can I solve the issue doing this?

If I’m running the program on older OS, Path is correct: “Macintosh HD:Applications:Prostage_System_Manager_2_14_beta_Mac:”

That’s when they started sandboxing apps.

See https://forum.xojo.com/46794-detect-app-translocation for a longish discussion. The TL;DR version for me was to make sure I’m delivering my app on a signed DMG.

I did try to deliver using a DMG (using https://c-command.com/dropdmg/ )
Same issue. Problem not solved

You need to package your app the correct way.
Resources should be internal, not next to the app. Use a CopyFiles step to copy the resources into your app.

If you are using classic FolderItem, use TPSF (http://github.com/devtimi/TPSF) to access resources.
If you are using new framework FolderItem then you can use the new framework SpecialFolder module to access resources.

[quote=388725:@Lukas Paul Truninger]@Michel Bujardet Yes. Precisely GetFolderItem("") path won’t contain /Applications

If I’m running the program on older OS, Path is correct: “Macintosh HD:Applications:Prostage_System_Manager_2_14_beta_Mac:”

[/quote]

Precisely, if you do not get /Applications in the path, it means the system has decided to execute the app in another, safe folder. That is a new feature destined to prevent problems with misbehaved application, so they are “quarantined” until macOS is certain everything is OK.

Stop using files in the same folder as the app bundle, and learn how to place read only files in Resources, or copy them into a subfolder or SpecialFolder.ApplicationData before opening them for write.

Apple has been discouraging placing files next to the application bundle at least since Mountain Lion.

BTW, I see that you are still using AbsolutePath. This too has been deprecated at least two years ago. You should replace it by NativePath or ShellPath. http://documentation.xojo.com/index.php/FolderItem.AbsolutePath

[quote=389159:@Michel Bujardet]Precisely, if you do not get /Applications in the path, it means the system has decided to execute the app in another, safe folder.

Stop using files in the same folder as the app bundle, and learn how to place read only files in Resources, or copy them into a subfolder or SpecialFolder.ApplicationData before opening them for write.[/quote]

From the time RealStudio crashed on too many pictures dragged into the project file, I still run a folderitem on loading graphics into canvas objects from within the application bundle. In the near future, I would either like to:

  1. Let the user copy all the graphic files (and sound files, if available in the project) copy to the ApplicationData path before using it.
  2. Drag all the files directly into the project now.

I would prefer to do the item 1 in the listing above, so I could also offer smaller application/game files for update.

Also, this behaviour needs to be updated for HiDPI/Retina-capable graphics.

You may safely “forget” that era if you’re using a modern version of Xojo. I constantly drag 100’s of PNGs into the IDE with no issues.

For this, you MUST use the IDE features and create the Image sets within the IDE. By enabling HiDPI for your app, when you drag an image onto the IDE, it creates an image set where you add the @1, @2, and @3 images.

[quote=389218:@Detlef Kahner]Let the user copy all the graphic files (and sound files, if available in the project) copy to the ApplicationData path before using it.
Drag all the files directly into the project now.[/quote]

You can do both, actually. You can drag as many files as you want into the project, they will nicely go in the Resources folder.

You can also in Xojo use a Copy File Step to copy all these files automatically to Resources without dragging them to the project. I don’t think RS had that method available, but I may be mistaken.

In one of my apps, user can add files by dragging them over the app, and they are copied into a subfolder within ApplicationData. A button opens a window onto the subfolder, so they can manage that at will.

Both methods are translocation proof.

Thanks Tim J. and Michel for the suggestions.

Quoted one is the method currently used within my projects (Copy File Step), but with custom made folder structure for now.

All other graphic files in these projects are Retina-capable already, but the Copy File Step ones are still not updated yet.

→ When a graphics file could be opened to be used as @2, could I still set an external Folderitem on it?
(If so, I still hope for item #1 in my listing above)

Be aware that Retina ready and being properly used in the IDE during a build are two different things. Unless you’re manually checking for the HiDPI status and only loading the proper resolution file manually, just haveing the @2 and @3 files aren’t going to get you there in Xojo.

I recommend that you dig through this for more details:

Xojo HiDPI Support