I’m testing a script which at some point performs this action:
set theCopy to duplicate theFile
set label index of theCopy to 7
This works fine when theFile is in my home folder. When it is on another Mac (as intended) I get error -10006, and the label cannot be set.
Event history gives me this:
duplicate alias "anderen:Documents:Testfolder:20090513 ERIK REED-Hendriks Bouwbedrijf.txt"
--> document file "20090513 ERIK REED-Hendriks Bouwbedrijf kopie.txt"
--> error number 0
set label index of document file "20090513 ERIK REED-Hendriks Bouwbedrijf kopie.txt" to 7
--> error number -1728 from document file "20090513 ERIK REED-Hendriks Bouwbedrijf kopie.txt"
Finder dictionary claims ‘duplicate’ returns a specifier.
But ‘document file “20090513 ERIK REED-Hendriks Bouwbedrijf kopie.txt”’ doesn’t look like a specifier to me.
This is the same event history when working with a local folder:
duplicate alias "Santanni:Users:thijs:Documents:@ Projects:Verbeeld:Testfolder:20090907 KEES REED-Alpro Soja Nederland.txt"
--> document file "20090907 KEES REED-Alpro Soja Nederland kopie.txt" of folder "Testfolder" of folder "Verbeeld" of folder "@ Projects" of folder "Documents" of folder "thijs" of folder "Users" of startup disk
--> error number 0
set label index of document file "20090907 KEES REED-Alpro Soja Nederland kopie.txt" of folder "Testfolder" of folder "Verbeeld" of folder "@ Projects" of folder "Documents" of folder "thijs" of folder "Users" of startup disk to 7
--> 7
Here I get a specifier. Is this a bug, or have I overlooked something?
And why does the reported error change from -1728 to -10006??
Remote events:
Never used them knowingly. Am I using them now? The script does not talk to the remote Finder to do the copy.
‘anderen’ is mounted on my desktop as a volume (but that may just be a mirage ; ).
All other actions of the script run without problems. This includes creating and writing a new file; opening, reading, changing, saving existing file (incl. changing its label).
‘duplicate’ duplicates, but does not return a usable specifier, so changing the label of the duplicate fails.
File specifier:
I figured you’re talking about this form:
document file “20090907 KEES REED-Alpro Soja Nederland kopie.txt” of folder “Testfolder” of folder …
‘theFile’ is returned from ‘choose file’, so it’s an alias.
I found I can coerce this to a file specifier with ‘set theFile to file theFile’.
Now I’ll just have to see which other part of my script that will break.
Might be safest to use a separate var to take the file specifier, and give that to ‘duplicate’, hmmm?
And while this may make the problem go away I would still like to understand the cause. That would help big time in avoiding making the same mistake again…
sorry for the confusion, while reading “remote file” I assumed you use Apple Remote Events.
Just forget it.
The same rule applies to shared volumes: Avoid alias specifier
Try this
set theFile to (choose file) as text
tell application "Finder"
set theCopy to duplicate file theFile
set label index of theCopy to 7
end tell
set theFile to (choose file) as text
tell application "Finder"
set theCopy to duplicate file theFile
set label index of theCopy to 7
end tell
Like before, it duplicates, but theCopy is not a valid specifier.
I thought of putting the second line in a try block, build the path for theCopy in the error handler, then set the label there.
But I can get absolutely nothing from the return value of ‘duplicate’ - it has no class…
Saying ‘theCopy as ’ just gives another error.
I have the path string for the original file, so I could make a path string for the copy from that.
Will work (knock wood) but feels crummy. Sigh.
Have you tried to circumvent the problem by creating a reference to the file after it is duplicated?
Besides that: Script Debugger’s dictionary says it returns a reference, that might imply that you should try using the contents of that reference as a specifier. But I haven’t tested it.
-- local file:
duplicate file "Santanni:Users:thijs:Documents:@ Projects:Verbeeld:Testfolder:20090907 KEES REED-Alpro Soja Nederland.txt"
--> document file "20090907 KEES REED-Alpro Soja Nederland kopie.txt" of folder "Testfolder" of folder "Verbeeld" of folder "@ Projects" of folder "Documents" of folder "thijs" of folder "Users" of startup disk
-- this is a valid specifier
-- remote file:
duplicate file "anderen:Documents:Testfolder:20090513 ERIK REED-Hendriks Bouwbedrijf.txt"
--> document file "20090513 ERIK REED-Hendriks Bouwbedrijf kopie.txt"
-- this only looks like a specifier
-- use or manipulate it in whatever way, and you get an error
This is the workaround I’m going to try:
set theFile to (choose file)
tell application "Finder"
set theCopy to duplicate file theFile
try
set label index of theCopy to 7 -- did it work? Fine!
on error -- else take the long road
set theContainer to container of theFile as alias as string
set theCopyName to displayed name of theFile & " kopie.txt" -- localised
set theCopy to (theContainer & theCopyName) as alias-- it already exists, no worries
set label index of theCopy to 7
end try
end tell
-- Actually the script already knows the container; it's a script global
-- So don't need that 1st line in the error handler
-- And: the script creates the files itself, with extension hidden
This what you had in mind?
[There’s a very small possibility that the problem is caused by some activity in the remote account. Checking that too]
Model: iMacs 20" (mid 2007 & mid 2009)
Operating System: Mac OS X (10.6)
“'anderen” is a user on the other Mac, mounted as a volume on my desktop. All actions of the script work fine, except setting the label on a duplicated file, because of the faulty specifier that is returned from the “duplicate” command.
Yes, the path is valid, as the file is duplicated.
I think I have the beginning of an explanation.
It’s voodoo
Well…
I was almost sure I’d seen a grey-labeled copy materialise some time yesterday.
Then, when I continued this afternoon, it failed again.
Just now, it worked.
The difference?
This afternoon our youngest was playing WarCraft III in that “anderen” account.
Right now, and yesterday, he was not.
I’m not exactly WoWed by this finding :rolleyes:
I’ll do a more rigorous test later.
Edit:
No, that wasn’t it. It worked, then didn’t work, then worked, then not.
@McUsr:
I didn’t say nobody was logged in, just that nobody was playing WarCraft III.
But I got curious: it appears that you can logout, and back into another account, then log out again, without breaking an existing connection. Last time I checked the remote Mac nobody was logged in. When I asked around my wife said she had been working in her own account - so she had logged out of “anderen” and into her own account.
And all the time “anderen” was mounted on my desktop, and I didn’t notice anything.