"duplicate file name" error using open for access

Scripting Forums AppleScript | Mac OS X
#1

Hi,

My script uses the following …

set copyYNInfoFile to ((path to home folder) as text) & “temp.txt”
set copyYNFileRef to open for access copyYNInfoFile
set myCopyYN to (read copyYNFileRef) as text
close access copyYNFileRef

This works fine on OS 10.3 but on 10.2 it fails and gives the error ‘duplicate file name’’ followed by the path to the file in question. If I click the ‘edit’ button on the error window it highlights the line where I try to ‘open for access’. I’m not sure what this error means or how to fix it. Is there a code solution to this?

Thanks.

#2

I don’t have a 10.2 install, so I can’t say. Is the syntax for this command any different than in 10.3? (Standard Scripting Additions.osax dictionary)

The command is supposed to check if a file exists and if it does, open it. If not, it creates it and opens it. It seems like 10.2 is trying to create the file even though it already exists.

Try changing the path to a file class specification instead of a string. You can try an alias too, but the path is supposed to be specified as a ‘file’

Try inserting one of these before the open for access line…
set copyYNInfoFile to (copyYNInfoFile as file)
set copyYNInfoFile to (copyYNInfoFile as alias)

Is it possible some other application already has the file open?

Does it matter if you add “write permission false”?

#3

Hi digest4d,

thanks for replying - I’ve been tearing my hair out over this, I’m not in the office now so only have access to my 10.3 mac at the moment but I’ll try these suggestions first thing in the morning.
At first I thought the file was still being held open by the application that writes it but I tried shutting the machine down and creating the file manually and its still the same.
The file doesn’t need applescript to have write permission but could you just show the exact syntax for using ‘write permission false’ as I don’t know where to add it.

Thanks.

#4

I can confirm that under some circumstances, 10.2 doesn’t tolerate incorrect file access syntax. The parameter for ‘open for access’ should be an alias or a file specification, not just a path string. Also, ‘path to home folder’ should be ‘path to current user folder’.

set copyYNInfoFile to (path to current user folder as text) & "temp.txt"
set copyYNFileRef to open for access file copyYNInfoFile -- NB. 'file'
-- etc.
#5

Thanks for your help on this guys.

I now use …

set copyYNFileRef to open for access copyYNInfoFile as alias

This seems to work OK now. Some of the other syntax suggested failed. I also changed to ‘path to current user folder’ - will backwards compaatibilty be maintained with that in future releases do you think?

Also is there any reason that I shouldn’t write temporary files to the current user folder?

Thanks.

#6

Future compatability’s never certain in AppleScript, but this one sounds hopeful. :wink:

I don’t see why not, though it would probably be neater to have your own Temporary Items folder either there or in the Application Support folder.

#7

Thanks Nigel,

Is there an easy way to target the application support folder as there is for the ‘path to current user folder’ - it would have to be supported on 10.2 and later?

Thanks.

#8

Yes indeed. For the user’s Application Support folder, it’s:

path to application support from user domain

-- eg.
(path to application support from user domain as text) & "My Temporary Items:temp.txt"

By the way, if you’re interested, there’s a slight, academic difference between these two expressions:

(path to application support from user domain as text)

((path to application support from user domain) as text)

Uniquely, ‘path to’ can take ‘as text’ as a parameter. In the first expression, that’s what it does and the string is returned directly by ‘path to’ itself. In the second expression, ‘path to’ returns its default alias and the AppleScript language coerces that to string. The end results are exactly the same, but the parameter version is about four to eight times as fast, depending on the folder. Even so, there’s only a few thousandths of a second in it. :wink: