Under Mojave, I’ve used CreateFileAtPath to create a file. When I run the script again to open the file I find that I then don’t have permission to open it even though the GetInfo pane says that I do.
Here is the snippet to show the creation code. Any ideas on how to overcome this?
set theFile to thePath & "/" & theName & "." & theMetaDataExt
tell application "Finder"
-- If the potential metadata file does not yet exist...
if (not (exists theFile as POSIX file)) then
-- Define the initial file content as a tag that can be searched.
set theInitialTag to "#NewMetaDataFile"
--- Create the metadata filename in the same directory as the document file...
set NSCurrentApp to current application
NSCurrentApp's NSFileManager's defaultManager()'s createFileAtPath:theFile |contents|:theInitialTag attributes:(missing value)
-- Associate MetaProxy with the new metadata file...
tell application "System Events"
set default application of ((theFile as POSIX file) as alias) to disk item myPath
end tell
Are you sure you have permission to access the directory?
There are a couple of other things I’d quibble with in your script. You really shouldn’t nest everything in a tell block like that (and you don’t need to use the Finder to see if a file exists). You’re also passing text to the contents parameter, when it requires data.
That said, I do appreciate your observations and will correct the noted issues. Not sure about what you meant by “data” not “text”. I thought the basic AppleScript data types only included:
integer
real
string
list
record
boolean
reference
date
I’m still learning how to translate AppleScript data types into what is needed in ObjC calls. Maybe I missed something in your book on this or perhaps you can suggest a reference that will help me to understand what AppleScript data type maps to what ObjC datatype. The bridging often makes things work even when I get it wrong. I’m used to much stricter typing that lets me know when I do something incorrectly.
By the way, I definitely have read write permission for the directory in which the file is being created. It’s on my desktop.
Also; if after having the app say that I don’t have the permission to access the file I just created, I open the file with TextEdit and exit without saving it, I can then get the app to open it without any errors. Strange…
The contents parameter specifies NSData, so you need to convert your string to data, something like this:
set theInitialTag to current application's NSString's stringWithString:"#NewMetaDataFile"
set theData to theInitialTag's dataUsingEncoding:(current application's NSUTF8StringEncoding)
It’s possible that passing the wrong type is corrupting the file creation, which might explain what you’re seeing. I say this because the only other reported cases of what you’re seeing involve quarantine issues.
I think we may have both been typing a response at the same time.
Sorry if it came out in a way I didn’t intend. I was only trying to say that I really couldn’t find a reference to a “data” type in AppleScript. That’s why I asked if you had any reference to the types.
That said; I poked around and I think I figured out how to do the conversion. Am I on the right track?
As always; your expert feedback is welcome.
set theFile to thePath & "/" & theName & "." & theMetaDataExt
-- If the potential metadata file does not yet exist...
if (not (exists theFile as POSIX file)) then
-- Define the initial file content as a tag that can be searched.
set theInitialTag to "#NewMetaDataFile"
-- To be succinct, define a variable for the current application
set NSCurrentApp to current application
-- Convert AppleScript string to NSString
set cocoaString to NSCurrentApp's NSString's stringWithString:theInitialTag
-- Convert NSString to NSData
set cocoaData to cocoaString's dataUsingEncoding:(NSCurrentApp's NSUTF8StringEncoding)
-- Create the metadata filename in the same directory as the document file...
NSCurrentApp's NSFileManager's defaultManager()'s createFileAtPath:theFile |contents|:cocoaData attributes:(missing value)
-- Associate MetaProxy with the new metadata file...
tell application "System Events" to set default application of ((theFile as POSIX file) as alias) to disk item myPath
-- And so on...
Thanks, Shane. I’ve got that part running with the added ObjectiveC call you noted.
I’ve found (by temporarily commenting it out) that what is causing errors down the road is:
tell application "System Events" to set default application of ((theFile as POSIX file) as alias) to disk item myPath
It is somehow messing with the privileges, so that even though GetInfo says they’re OK. I can even open “theFile” outside the App using TextEdit App. The issue is that my MetaProxy App can’t open it without an error about not having the correct privileges.
The goal of the noted statement is to set “theFile” (a meta file) to open by invoking my MetaProxy App when I double-click on “theFile”.
Now, I have had no luck finding any formal documentation on this way of setting the default application for a specific file. The best I could do was find an example (and not a really clear one). Perhaps I’m messing up the call or data types. Are you familiar with this call, know whether it’s still valid (not depricated in Mojave) and what the data types should be?
As I’m trying to “learn by doing”, I don’t expect the answer on a silver platter. A reference to consult would be just fine or even just a nudge in the right direction.
If you think that an ObjectiveC call would work better, please let me know. At least I have the formal doc for ObjectiveC and can see what I can do using that.
It may be that your application is not properly registered with the Launch Services database – it’s hard to say. But if you’re creating documents meant only for your app, you should be able to give them a unique extension, and then use Script Debugger to make your applet respond to such documents.
Thanks. The situation with permissions was starting to get worse. As I had backups, I was in a position to re-image my machine.
I’d like to ask a question, so I don’t end up thinking that my AppleScriptObjC programming is at fault when it could be the files that are corrupt.
I have two options to restore data files. The first is to copy them of my backup drive and the other is to restore via time machine. I don’t know if either or both methods set permissions properly as part of the copy/restore operation. Could I ask for the benefit of your experience on this?
Once I’ve got them back on my drive and I’m sure the permissions are OK, then I’ll try my App again and see if the issue has gone away.
Fortunately for me, I don’t have any recent experience of this sort of issue. I don’t think it would make much difference, though. However, I’d be concerned about the possibility of hardware problems.
Hi Shane. Hardware problems? I’m sorry, I don’t understand. The computer is re-images and is working well now. The concern is that messed up permissions could be brought back onto the computer by using the wrong method of restoring them.
Oh well… Guess I’ll just have to try a few files and see.
I need to get back to debugging the script and am just being very careful. I’m not sure how the permissions got messed up. The script only tries to create .meta files. However those don’t seem to be the ones messed up.
I got all the permissions squared away. The permissions issue was my failure to cast the string filename "as POSIX file) in the “open” command. It appears that this requirement came into being about the time the new security protocols were introduced. So, I think it has something to do with that.
Another issue which made things difficult to figure out was the behaviour of files with the quarantine flag when used with drag and drop. The assignment of the quarantine flag to files which were created solely on my computer appears to be a system issue and not in my power to fix. Running the “xattr” command over them is an inconvenient but necessary kludge.