I experience looping in macro using trigger This folder xxx adds an item ignore partial or changing file in case of Duplicate File Action.
What is the best reliable way to avoid such looping?
Thanks for any hints/solution,
–Alain
If you duplicate a file in a folder you are monitoring then clearly the new file will trigger the macro.
You cannot avoid the macro triggering (except perhaps by disabling the macro, but that would be problematic since you don’t know how long the duplicate might take and then there is a period of time afterwards while Keyboard Maestro waits to see that the file has sopped changing).
You will need to adjust your macro to ensure it does nothing with the duplicated file, probably by looking at the file name and seeing if it is a duplicated file, or perhaps keeping track of files to ignore or something like that.
But even worst trigger occurs when I simply rename a file in the monitored folder (using Path Finder outside of KM) which is not actually an real addition…
Is there a kind of file UID for a reliable filtering management inside the triggered macro?
I mean a lighter/smarter solution than MD5 computation 
–Alain
Renaming a file is (as far as Keyboard Maestro’s Folder Contents trigger is concerned) the same as deleting and creating the file.
I believe file’s have some sort of uid on HFS, but Keyboard Maestro has no way to get it, and I’m not even sure whether all file systems would have it, but presumably you are only interested in HFS. Some sort of JXA might be able to extract the uid. But I have no idea how you would go about doing that.
Alternatively, you could try to recognize the file based on the extension and file size and maybe an md5 of the file.
As for the trigger Folder you propose a choice:
- adds an item
- removes an item
- adds or removes an item
hopefully at least there is a technical way to distinguish between adds / removes.
What about overwrites (which don't trigger at present)?
As adds (may) induce some misunderstanding why not change naming to more accurate adds or renames?
The solution seems to used inode invariant in renaming:
--Alain
(bumping an old thread, running into the same challenge).
I have a folder trigger to process files added to a directory - namely convert & rename. As noted above, this can endlessly re-trigger the macro, and similarly, wondered if there was a way to distinguish between a renamed file and a newly added one. (like with a unique file ID)
a couple approaches:
-
within the macro, filter on files I know will create a loop - as is done above. Ie, if I'm converting to PDFs, enforce that no new PDFs are added to that folder. Then if the macro sees a PDF file, it exits out since it knows it was created by the macro itself. It's imperfect and adhoc. It makes the workflow less flexible - maybe in the future PDFs could land in this folder, and I'd like them to still be processed by the other steps of the macro.
-
2 stages: the macro watches folder "StageOne"; its first action is to move files to folder "StageTwo", and operate on them there. (StageTwo does not have a trigger of course, so changes there won't cause a loop). It's a bit of added code since I no longer have the convenient trigger value pointing to the file I'm processing. A few lines of AppleScript to move the file, and store its new location.
(edit: KM variable instancenewfile was set to token %TriggerValue%)
for anyone else in the same boat, curious for other ideas. And also - definitely learn about instance variables. They're crucial for making this kind of thing work.
As above, you can use the inode info to tell if a file is new or just renamed:
$ touch myfile.txt
$ ls -1i
19699743 myfile.txt
$ mv myfile.txt mynewfile.txt
$ ls -1i
19699743 mynewfile.txt
$ touch otherfile.txt
$ ls -1i
19699743 mynewfile.txt
19699754 otherfile.txt
$
Notice that the inode of the renamed file didn't change, while the new file gets (obviously) a new inode. The stat command above can do more, as shown in the example the user attached.
Not sure that solves the problem, but inodes are the definitive way to determine new versus renamed.
-rob.
Thanks, I saw that mentioned, but I don't see how the macro can make use of it, outside of keeping a list of "known" inodes. Now if the trigger mechanism were watching inodes, it could use that info to avoid loops by only calling the macro for new inodes.
Not that I'm suggesting that as a default behavior, since it'd certainly break something else.
Yea, I was thinking you'd have to build some sort of inode table, which would probably have to use a global variable. When the macro gets run, check if global exists. If it doesn't, use ls -i to capture the inodes.
When the macro is triggered again, it would see the global exists, then you'd check the new addition's inode against that list, etc.
Not ideal, just trying to think of ways around the problem.
-rob.
Could a semaphore lock work here?