Weird failure of the Finder's duplicate command

AppleScript
#1

In the Finder, I’ve selected a folder which contains a single file named mac1024.png. I want to make a copy of that file with the name icon_512x512@2x.png and then rename the original to icon_1024.png.

This script works. Before running it, I make a copy of the folder and then run the script on the copy, because I’m not a maniac:

use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions

tell application "Finder"
	
	set theseItems to selection
	set thisFolder to item 1 of theseItems
	
	set folderFiles to every file of thisFolder
	
	repeat with thisFile in folderFiles
		
		set oldFileName to name of thisFile
		
		set newFileName to "icon_1024x1024.png"
		set new2xFileName to "icon_512x512@2x.png"
		
		set new2xFile to (duplicate thisFile to thisFolder)
		
		set name of new2xFile to new2xFileName
		set name of thisFile to newFileName
		
	end repeat
	
end tell

I have another version that I can run on the original folder because it makes a copy of it for me and then operates on the copy.

Only, it doesn’t work. The line that duplicates the PNG file fails with “An item with the same name already exists in this location. (-15267).” The only difference in the code is the three lines after the comment:

use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions

tell application "Finder"
	
	set theseItems to selection
	set thisFolder to item 1 of theseItems
	
	-- Duplicating the folder here causes an error 
	-- when we try to duplicate the file later. 🤨
	set parentFolder to container of thisFolder
	set newFolder to (duplicate thisFolder to parentFolder)
	set folderFiles to every file of newFolder
	
	repeat with thisFile in folderFiles
		
		set oldFileName to name of thisFile
		
		set newFileName to "icon_1024x1024.png"
		set new2xFileName to "icon_512x512@2x.png"
		
		set new2xFile to (duplicate thisFile to thisFolder)
		--> An item with the same name already exists in this location. (-15267)
		
		set name of new2xFile to new2xFileName
		set name of thisFile to newFileName
		
	end repeat
	
end tell

I can’t figure out why Finder can duplicate the file as mac1024 2.png in the first version but forgets to increment the filename in the second version. Anyone?

#2

As an aside, I tried to (maybe) get around it with @ShaneStanley’s FileManagerLib, but this line fails in both versions:

copy object thisFile to folder thisFolder new name new2xFileName

It gives me Finder got an error: item 1 of {document file “mac1024.png” … } doesn’t understand the “copy object” message. Do I have the syntax wrong?

#3

That means you’re passing a Finder reference. You need to pass an alias, file, HFS path or POSIX path.

#4

Hi.

In your first script, the Finder creates the duplicate in the same folder as the original, in which case it’s prepared for the impending name clash and increments the name for one of the files. In the second script, it attempts to duplicate a file from the duplicate folder to the original folder and only discovers the clash then, treating it as an error.

#5

Edit: I see the error in the code. Let me fix that and see if it clears things up.

#6

Yep, I meant to refer to newFolder in this line, not thisFolder. Gonna rename the latter to masterFolder for clarity.

set new2xFile to (duplicate thisFile to newFolder)

Now it works. Dunno how I managed to miss that even after stripping it down to the bare essentials.

So apparently, the Finder is more aware of what’s in the source folder than the destination. Curious.

#7

Another way to have the duplicate appear in the same folder as the original is simply to omit the to parameter from the command. The default destination is the folder containing the original. In this case, it’s absolutely necessary for one of the items to have a different name.

When duplicating to a different folder, duplicate behaves much like move if there’s already an item with the same name at the destination. It throws an error for safety. Both commands have optional replacing paramaters which allow the existing item at the destination to be overwritten if that’s what’s wanted.

It’s pretty much the same when things are done manually in the GUI.

#8

Even better then. Less room for confusion.