And even applications that use Cocoa scripting. But it’s worth keeping in mind that anything sandboxed needs file references, not just paths.
Hi.
Here’s some logic over which to mull:
-
‘close access’ + file specifier closes an unspecified access to the file, provided that the access is owned by the application running the script. If the application has several accesses open to the file, ‘close access’ + file specifier will close one of them, but you can’t know which.
-
‘open for access’ without write permission will only ever error if the path to the file’s incorrectly specified. In this case, using ‘close access’ ” whether with the incorrect file specifier or with the non-existent ‘open for access’ number ” is a waste of time.
-
‘open for access with write permission’ will only ever error if the path’s incorrectly specified as above or if the file’s already open with write permission. If some other application owns the write permission access, the script won’t be able to close it, so again using ‘close access’ is a waste of time. If the write permission access belongs to the script and is left over from a previous run, ‘close access’ + file specifier may close it, but it depends on point 1 above.
My own view is that it would be better to catch ‘open for access’ errors separately so that their causes can be investigated and fixed. If they’re the script’s fault, it would be better to fix the code causing them than blindly to close accesses. Something like the following, although I don’t usually bother with the first ‘try’ block myself:
try
set fileDescriptor to (open for access file aFilePath with write permission)
on error errMsg
display dialog errMsg buttons "Stop" default button 1 cancel button 1
end try
try
write stuff to fileDescriptor
-- do other stuff
on error errMsg
display dialog errMsg buttons "Stop" default button 1
end try
close access fileDescriptor
From the description:
Of course that’s very old…
And there’s always:
use framework "Foundation"
(current application's NSFileManager's defaultManager()'s contentsOfDirectoryAtPath:posixPath |error|:(missing value)) as list
Thanks, I thought it would but wasn’t sure.
@Nigel: If an error occurs while writing and the script hangs (read: write command doesn’t have a timeout) or unexpectedly quits, the second run your example code won’t be able to close the file properly because in your example you only close the file by it’s descriptor. I understand the problem of closing an file with read access opened by another application, but that is solved with an extra try around the closing in Stefan’s post.
How awkward, now I saw it clearly, I actually did, believe it or not, look it up in the Scripting Additions dictionary.
@Nigel, it of course depends on who it is sitting there, having problems with a file handler one can’t close. Say if one that hasn’t experienced this problem before, sits there, then it is better to close the file reference all together, so that the person in question can move on, without the befuddlement. And thanks for the writeup. 
Other thing is file reference of file system, and other thing - file descriptor (of current application, many users name its variable fileRef, but its correct name is fileDescriptor for example).
This should close your opened descriptor (that is, to force the current application to forgot the file descriptor)
close access fileDescriptor
– close stored in the script file descriptor
If in advance, when opening a file for access, you did not save this descriptor to the script variable (fileDescriptor), then this means: your script has completely lost control over the file descriptor. In this case, you will have to restart the application for it to close all file descriptors.
Hi KniazidisR.
Please don’t keeping replying to topics that ended months or years ago. I’ve asked you many times.