So I found an old post on here that explains how to create a shortcut for a menu item that is several clicks deep. ie Tools->Apply Rule->smartrule name
It seemed to work fine, or so I thought. The rule was designed to take the selected file and copy it to a new shared folder. The original file would be labelled and tagged as well as having a date added to its filename. Now, in the database, I know that all files labeled red and having that added date have already been processed. That rule has worked perfectly for months.
HOWEVER, when applying the rule to a selected item using the keyboard shortcut I created, the rule now applies to THE ENTIRE DATABASE. So, overnight, without me realizing it, my rule ran on 100,000+ items, turned the entire database RED and left me with 100,000 duplicates and no way to know which were “accidents” and which were already done.
So, you would think the process for me now would be to find all of the files modified after the mishap and undo the labels, HOWEVER, for whatever reason, changing the name of a file, and the label did not count as “modifying” it. I guess because changes were only in DT and not in the file system. Any suggestions on how to find files that were acted upon in the last 24 hours???
If they are red, they are replicates (rather than duplicates), unfortunately - removal of which seems currently impossible to automate. Furthermore, replicates have the same added date as the originals (duplicates would have their own added date, which would have made it possible for you to discern which ones were created in the past 24 h).
Which date was added? Would that be a way you could discern those files changed recently? It would be possible to change e.g. the created date (or a custom metadata date) based on a date in the file name if that helps.
thanks Blanc, I appreciate your looking at this. I can’t access DT now because I’m having to rebuild. I do have a backup but it’s on BackBlaze, so restoring it will take close to a week. But at least it’s there if I have no options.
The RED files are red because I chose the RED LABEL not because they are replicants. The date is an effort to add creation dates to blog posts etc imported from DevonAgent because for reasons I don’t understand when Devonagent imports a blog post it simply gives it today’s date, not the date of the article. So the dates added are all different. The other thing the rule does is add a reference in the file name to the GROUP the file came from. That’s because the groups are named for search sets in DevonAgent.
So, file goes from being named:
This is a blog post from Devonagent.pdf
to #devonagent questions# This is a blog post from Devonagent (2003-12-10)
I would have expected those changes to alter the file’s MODIFIED DATE but it does not. I checked info and looked at all the columns and none of them reflect this recent work on the file in DT.
Just chiming in here to say that Backblaze does not back up a lot of metadata / extended attributes in case this isn’t known. I’m not sure how it behaves with a Devonthink database, but when restoring Finder files, things like tags and modification/creation dates are all lost.
Just FYI, I found a solution that MIGHT help someone someday.
The rules run but do not impact the file itself - even with a name change. But what that means is that the READ/UNREAD status is also unchanged. So the rule ran on 95,000 files and changed their names and attributes but did not change them to READ. So the smart group of UNREAD items contains all of the files that were altered accidentally. I can select and remove the problematic red label.
How did you exactly set up the shortcut? All items of Tools > Apply Rule should be disabled without a selection (just checked this), maybe your shortcut was valid for Tools > Perform Rule too as the shortcut definition used only the name of the menu item, not its full path? At least this would explain the issue.