Broken File Droplet

Can anyone shed light on what I’m seeing here because I’m at a loss.

I’m working on a script droplet and was having trouble parsing the files dropped on it in the Finder.

I’ve minimized the code to this example:

on open (theFiles)
	display dialog (count theFiles)
	repeat with eachFile in theFiles
		display dialog (name of (get info for eachFile))
	end repeat
end open

(yes, I know this uses deprecated ‘info for’, but this is just quick and dirty and that’s not relevant to the issue at hand since the first line demonstrates the problem).

Saved as a droplet application, it should be pretty clear to most people what it’s trying to do - report the number of files dropped, then display the name of those files in turn. Pretty simple, right?

The problem is that it doesn’t work correctly for files in my ~/Documents folder for reasons I cannot understand.

Let’s say I have 10 documents in my ~/Documents folder named A through J and I select groups of files in alphabetical order

Here’s what I get:

Files Selected Correct? # reported A B C D E F G H I J
1 TRUE 1 X
2 1 X
3 2 X X
4 2 X X
5 2 X X
6 3 X X X
7 3 X X X
8 3 X X X
9 3 X X X
10 4 X X X X

The list goes on.

Now it gets really complicated. I can select ANY combination of these files, and the same ones will always be detected/undetected - e.g. if I pick C, D, E, F, G I will get two files (C & F) reported, UNLESS I pick only ‘unblessed’ files that are not normally reported (e.g. I pick unblessed files B, D, E, G) in which case I get them all.

So there is nothing peculiar that I can determine about the files that do or do not work. They are a combination of .pdf, .xlsx, .scpt, .txt files, (except for folders which always seem to work, for some reason).
The files have a series of dates which don’t seem to matter (it’s not only files created in a certain time period)
File size isn’t relevant (files from 0 bytes to several megabytes)

Even more confusingly, I cannot reproduce this in any other folder, including subfolders within ~/Documents, unless I copy unblessed files to a different folder, in which case they continue to be unblessed (I recognize this may be due to limited sample size - I haven’t checked every file/folder on my drive)

Additionally, if I duplicate an unblessed file, the duplicate is also unblessed.
If I duplicate a blessed file, the duplicate is also blessed (so the problem sticks with the file?)
Either way, I think this discounts iCloud/Desktop syncing issues.

Before I lose much more hair, can others try running the script to see if it’s a problem with a) the script (I don’t think so, it’s about as vanilla as you get), b) the Finder, c) my ~/Documents

Thanks
:slight_smile:

OK, here’s the issue. AppleScript has had this bug for a long time.
If you save the droplet as a stay-open app, the “on open” routine will actually get called twice.
Some files will be in the first run, and the rest in the seconds run. They will not all be in one run.

We do not to know why it does this or with what criteria it breaks them into two lists.

In previous scripts on this site, some people have setup the script to have the “on open” add the files to a global list or property. Then each run will add to the list, eventually getting the list to contain all of the dropped files. Then they used an “on idle” routine to then process the list as a whole.

Here is a script to test…

property totalFiles : {}

property todo : 0
property isone : 0

on open (theFiles)
	set totalFiles to totalFiles & theFiles
	set todo to todo + 1
	beep
end open

on idle
	if todo = 2 then  -- the on-open was run twice
		display dialog (count totalFiles) giving up after 2
		repeat with eachFile in totalFiles
			display dialog (name of (get info for eachFile)) giving up after 1
		end repeat
		set todo to false
		quit
	else if todo = 1 then
		if isone = 2 then -- it idled 2 times without adding to list, so update todo so it continues
			set todo to todo + 1
		end if
		set isone to isone + 1
		return 0.5
	end if
end idle

Save this as a stay-open standalone app

1 Like