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?
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
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.
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.
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.
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:
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.
