Droplet not taking all files dropped on

We have an utility to process images, built as a standard droplet (using the code floating around with distinction between folders and individual files).

On one installation (MacBook Pro, macOS 11.5), dragging on a single folder works fine, but when dragging on a selection of 4 files, only 2 get processed. An alert at the beginning of the code confirms that only two files are “taken”. Various tests by exclusion show that we have a set of 2 specific files which make the other 2 not being processed. If in the group we drag onto the droplet, one of those files is included, only that one gets taken.

On other installations (iMac, macOS 11.5 or virtual macOS 10.14), this effect does not show up with the same files.

Has anyone heard of such an effect? What can be the cause? What can be done to avoid it?

Any hint is highly appreciated.

Thanks a lot in advance.

This can happen if the files have quarantine flags set. Were they downloaded from somewhere? If so, have you moved them from the Downloads folder?

Thanks for the very quick response, Shane.

The files are all examples form clients we are allowed to use for our tests. So, they were downloaded in one or another form. Some of them have been floating around on our system for years. They are also moved around from volume to volume. I am not sure if the ones in the first group came in via download or via copying from a transfer disk/stick (my partner gets those samples in various ways).

The weird thing is that the files all work if dragged on alone. And if that group of four is in a folder, and we drag on the folder, everything works fine.

It is a really weird situation, and I am getting balder and balder form scratching my head :slight_smile:

That’s typical behavior for quarantine issues. It’s not that files get rejected, so much as a delay while they are checked, by which time processing of the first lot has begun.

OK. Sounds logical.

The question is how to get rid of that Quarantaine flag?

So, this would be a timing issue?

Did a bit more research about the Quarantine flag, and SuperUser (command line - How to clear (remove) macos extended attributes recursively from a directory? - Super User) had the solution.

(now for the record:)

Additional flags can be displayed with ls -l@

And, yep, all the files had the Quarantaine flag set (plus some had additonal ones)

xattr -d

gets rid of those flags for a single file, and

xattr -rc

does it for the content of a folder.

I did the latter, and then all files processed properly.

So, thanks a lot for the hint.

As the problem occurs before files are accessed within the droplet, I will have to make a little utility which strips those attribute before the files are dragged onto the droplet. (maybe a bit difficult to explain to the MSUI (Most Stupid User Imagineable), but would work.

Could you incorporate the xattr -rc into your open handler?

Something like
do shell script quoted form of posix Path of myFile & " xattr -rc

The way I understand the situation (please correct me if I am wrong) is that the effect happens before the open handler kicks in. And therefore, it comes too late. But yeah, that was one of my reasonings.

Actually, even more focused would be

do shell script quoted form of POSIX path of myFile & “xattr -r -d com.apple.quarantine”

But, as stated in the other answer, we don’t get there with the affected files

It’s a known bug in the application:openFiles: delegate method. it may or may not be caused by the quarantine issues mentioned earlier, but it’s a serious bug nevertheless.

I stumbled upon it years ago and have a workaround implemented in my apps that I found here (at the bottom):

Basically you need to have a global array that you watch as it fills up with files, then invoke your processing method once you’re sure no new files are added. Don’t know if it’s helpful for you as it’s in Objective-C but you might be able to replicate it in AppleScript.

The easiest solution is generally to just move the files to somewhere other than where they were either downloaded, and in the case of unzipped files, moving the files and not their containing folder.

But you can also modify your script to deal with it. There’s an example in this thread:


Thank you for the lead. Well, attempting bring that to Applescript is a bit beyond my capabilities for now…

The link I posted is to an AppleScript solution.

Yep; that was my answer to @leo_r’s answer.

Unfortunately, the sample in your link does nothing for me. However, as dropping a group of files is not recommended anyway, we move the issue to instructions (if you have unexpected behaviour, put the files in a folder and process that one).

In any case, thank you very much for your help; it did put light onto an otherwise very weird issue.