I am having a problem with OwnerRead that I don’t understand. Before adding a file to the list of usable files, I test for various potential problems, including OwnerRead. I have many files that have OwnerRead set False. When I look at the information in Finder’s properties, it doesn’t show. I suppose I could reset any file, but I’m still left with why I can’t find it outside of XOJO.
One other piece of info is I transferred the files from my PC to my Mac. That shouldn’t matter since it should show up in Finder’s Info.
What do you mean by “Finder’s properties” ?
Do a cmd-I on the file and look at the permissions stuff at the bottom.
You may also want to check the file flags in a terminal. That’s where these come from. The Finder adds the users and groups information.
Yes. Tim. When I do Command I and look at the bottom it says I have read and write privileges.
I don’t use terminal. What can I do in Terminal?
Terminal will show you the underlying Unix file flags the Permissions come from: Unix File Permissions
If you go to the Terminal and type ls -al, you’ll get a list of files in the directory. The first part that looks something like drwx------ are the permissions. This is where Xojo’s Permissions object presumably gets them from. If they don’t match, that would be a bug.
Maybe you can provide an example of debugger output, the Finder Get Info view, and the Terminal file information for the same file?
Thanks Mathew. I’ll work on terminal.
This is a line of permissions for a file.
-rwxrwxrwx 1 arthurgabhart staff 46938 Aug 20 16:16 GuGyeongHaDa.wav
I don’t see anything wrong.
Below the code is an info window for a file in the directory. I have 3000 files and hopefully I picked one of the “bad” ones
Here’s some of the code I use. This is the part for Mac and permissions.
#If TargetMacOS Or TargetLinux Then
Var p as new Permissions(tObj.Permissions)
if p.OwnerRead = False Then//3
strMsg = "Caution with this " + fType + " File: " + tObj.Name + EOL + "You Cannot Currently Access It."
If mMsg Then
#If TargetWindows Then
bmsg = New BoxMssage( 0, strMsg, tObj.Name, CurrentMethodName )
#Else
MessageBox strMsg
#EndIf
End If
MsgStrd = strMsg
Return 3
elseif p.OwnerWrite = False Then//4
strMsg = "Caution with this " + fType + " File: " + tObj.Name + EOL + "You May Need to Change" + EOL + "this File's Permission to Read & Write."
If mMsg Then
#If TargetWindows Then
bmsg = New BoxMssage( 0, strMsg, tObj.Name, CurrentMethodName )
#Else
MessageBox strMsg
#EndIf
End If
MsgStrd = strMsg
Return 4
End if
#EndIf
The Finder info and directory listing look correct. So you are saying that, in your code, the line that tests for p.OwnerRead = FALSE executes? If so, have you looked at p in the debugger? Make sure it is the same as tObj.Permissions. Note the the constructor for Permissions takes an integer which is the bit-flag version of what you saw in Terminal (e.g. 777).
Is there a reason in that line you aren’t just using tObj.Permissions directly, e.g.
if tObj.Permissions.OwnerRead = False Then
Interesting. I looked at “p” and all of the permissions have all become false.
Thanks. I think I stole it from the LR. I’ll have to look deeper at the code.
That is correct. I also have tried to play a few of the files and it throws an error on play. (It’d probably be a good time to get that code right for file errors.)
Welcome to “Modern” macOS Security. It is 100% possible for your User account to have access to a file, but not an application.
I would approach it from this direction.
Create a new project in Xojo, enable the support for files to be dropped into the main window. On file drop, provide permissions info that you obtain using the Xojo framework (avoid using a shell to be on the safe side).
If this application has the ability to read the file, then this is a “Security” issue. If this application does not have the read ability, then the problem is with the various permissions on the file.
If it is the file, you can try using Permissions Reset 2 to blast almost all of the permissions and settings on the file.
If it’s not the file, then you need to look at the code you use to access the file. Does your application just access the music folder, does the user have to select it first?
I think that might be the problem. The user selects the folder a long time ago. It’s set in the preferences. But it doesn’t make sense elsewhere. The confusing part of this, I have other exercise files that I don’t have the problem with this.
However, if I use the same code that works with another set of files on the same folder of sound files, it works, but this set it doesn’t.
On the other set of exercises, the permissions are correct - true.
On this set - false
As a general rule of thumb, Apple now decree that apps should ONLY be granted to access files in the users space, with an action from the User. This can be done via asking the user to select the location in a open folder dialog or via Drag and Drop.
Depending on the location, this can also be done via setting “Usage messages” in the application’s property list., and will present a dialog to the user asking if they want to allow the application to access a certain folder.
These can be set by using the “Capabilities” pane of App Wrapper 4, the folders available for this are as follows.
- Desktop folder
- Documents folder
- Downloads Folder
- Network Volumes
- Removable Volumes
There are also “Usage strings” for accessing the following, but I am not 100% this includes the folder or just the data via API.
- Music
- Photos
App Sandboxed applications can access the following locations, but placing your application in the App Sandbox adds another world of pain.
- Downloads
- Movies
- Music
- Pictures
1 Like
To the OP’s findings, then, is it the case that the Permissions attribute of the Folderitem reflects the effective permissions (what the app has with respect to a file) rather than the user permissions that we can see in the Finder? This might be practically correct, but probably needs to be documented, or there’s a bug here. It would seem that, since these can be manipulated by the Permissions attribute, some indication that this isn’t going to work due to another layer of security is really needed.
That might solve my problem. For some reason, I thought these wouldn’t be able to be set.
Well, that’s the question. The problem is they don’t match what you see in Finder/Terminal. If Sam’s hypothesis is right, Mac OS security is causing that to happen and what you see is correctly reflecting what permissions your application has. But a problem with this is that it doesn’t correctly reflect the file’s intrinsic permissions, which is what you (and most people) expected in your code – that really needs to be documented (and it would be good to have a way to get the intrinsic permissions, for example if you wanted to write a Finder-like app that displays them).
Of course, it might just be a bug, too…
FWIW, the Folderitem.Permissions documentation indicates they can be set, but I’d expect if your app doesn’t have access to the file, you shouldn’t be able to successfully set them, either.
Thanks for making it clear, and I want this to happen, so if things don’t work, I’ll file a feedback
The Finder is just another app. If you can fake a Xojo app, you certainly can fake the Finder the same way.
BTW it is an assumption based upon witnessing very similar behavior. In my case the file had an extra attribute com.apple.macl (which cannot be easily removed by an application). It is an undocumented security system introduced with macBS. I have two copies of an application, one can access it and the other cannot.
Code wise, yes. However Apple give themselves functionality that we can’t see, don’t even know exists or in the case of the App Store, they even utilize App Sandbox Entitlements as a means of making their apps appear better over competitors, private undocumented entitlements and such.
Thanks.
Oh yes. All this upsets me so much that I do the most I can to forget about it. Probably one reason I use an alternative to the Finder as well 
.
I have good news about my problem. I could change the setting for OwnerRead.
Here’s the code.
#If TargetMacOS Or TargetLinux Then
Var p as new Permissions(tObj.Permissions)
if p.OwnerRead = False Then p.OwnerRead = True
//The above line solved it.
if p.OwnerRead = False Then//3
//breakpoint that never gets uhm broken
strMsg = "Caution with this " + fType + " File: " + tObj.Name + EOL + "You Cannot Currently Access It."
If mMsg Then
#If TargetMacOS Or TargetLinux Then
MessageBox strMsg
#EndIf
End If
MsgStrd = strMsg
Return 3
1 Like