I'm working on a macro that runs when the Applications folder is modified—I want it to run when a new app is installed. I have it set to trigger on adding an item to the Applications folder, and to ignore partial or changing files. I have a dialog appear to do some stuff to the newly-added app, but the problem is it's showing up too early: It appears as soon as the copy starts, not when it finishes.
I'm pretty sure that's because an application is a bundle of many files, each of which is complete (so they're not partial or changing, even though the overall app bundle is changing). If I could see it, I expect my macro is triggering many times, but only the last one "sticks," when the app bundle is complete. If I add a semaphore lock, I imagine my macro will break, as the first-copied file will get the action ... so in that sense, I don't want to break my macro by doing what I should do, which is to lock it. 
So it's working, as the action I take in the dialog is applied to the app bundle ... but ideally, I don't want my macro to start until the app bundle is fully copied into the folder. I can't really check that Finder is busy copying (I don't think), as the macro triggers on changes to the Applications folder. Maybe there's some way to check for the "app bundle.app" filename first?
All ideas welcomed!
-rob.
I take it back ... I added a semaphore lock/unlock pair, and it still seems to work. So now my question is why does it work? There are literally hundreds of files being added to /Applications when I drag an app in ... I guess/assume because the folder (nee app bundle) is the first thing created?
-rob.
As you note, Keyboard Maestro probably cannot detect this reasonable.
Presuming the package folder itself is created early in the process, then the folder itself wont change from there and the macro will trigger. I would expect.
A semaphore lock will only stop this macro from running past the semaphore lock action while another macro has already passed a matching semaphore lock action. So I don't see how this would affect anything unless there is another macro involved.
I actually found a way to get this working. I set two variables (OldSize and NewSize). OldSize is set to -3 (just to make sure it doesn't match any real values) to begin, and NewSize is set to the value of this shell command:
du -s $KMVAR_NewAppPath | egrep -Eo '\d+'
That returns the size of the app bundle, and it's constantly growing as it's copied. Once both values are set, I enter a loop that sets OldSize to NewSize, then recalculates NewSize, and pauses a very brief amount of time. The loop exits when both values are equal, which only happens after Finder has finished copying the files.
Once the loop exits, the macro continues, and I know that I'm working with the full final app. It may not be pretty, but it works!
-rob.
3 Likes
And now, I realized I was making this so much more complex than it needed to be. The overall concept is the same, but much simpler in implementation:
execute actions until conditions met:
get local_size1
pause 1 second
get local_size2
until: local_size1 = local_size2
No need for swapping the settings, just track both until they're equal and that means the copy is done.
-rob.