Bug with 'duplicate' on remote file?

Hi,

avoid always alias specifiers while sending Apple Remote Events. Use Finder file specifiers instead

Hi Stefan,
I’m entering terra incognita now…

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…

Regards,
Thijs

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

Sorry for creating the confusion!

And solution refreshingly simple.
Thanks.

You’re welcome.

I’m looking forward to the world cup final Netherlands vs. Germany :slight_smile:
Although I’m german the Dutch deserve their first star

Yes, it could happen.
But maybe the dutch team will fear l’histoire qui se repète…
I should hope not.

(It appears Kaapstad is already turning orange. Poor Urugay.)

Hello

@Thread: Thanks for great information Stefan.

@Football: Whatever as long as it isn’t in favor of Juventus! :slight_smile:

Best Regards and good Match

McUsr

Torino? Italy is licking it’s wounds :wink:

Hello
:smiley: I have no grudge against Italy. :slight_smile: Only Juventus :slight_smile:

Best Regards

McUsr

Well, this does not work:

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…:confused:
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.

Hello

Could you please show us the error message from an on error e number n statement within a try end try clause?

Best Regards

McUsr

That error & number are shown in the first post.
You can also see that “duplicate” is successful (error 0), but does not return a valid specifier.

Error Codes says:
“-1728: errAENoSuchObject - e.g.,: specifier asked for the 3rd, but there are only 2.”

Yes, obviously. It’s not a full path.

I’m stumped.

Hello.

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.

Best Regards

McUsr

-- 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)

Is “anderen” the name of the shared volume? Is the path valid anyway?

“'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 :smiley:

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.

Hello

I find it odd if it works when nobody are logged in, but don’t work when somebody is logged in.
It may be logical, but not by intuition!

Best Regards

McUsr

Somebody else bumped into this bug as well.

So it’s the workaround.

@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.

Hello

Thank you very much for the link.
It is nice to figure out what goes wrong.

Best Regards

McUsr