I find it unfitting for a lot of use cases for the index folders way of working that deleting a note within DT does not delete the file in the file system unless database trash is emptied. What do you think about having an option to delete right away? Or what am I missing about why it is implemented that way? If I for example index a cloud folder I am sharing with a teammate and personally do all the interaction through DT whereas the teammate does everything through the normal file system (on his PC, not mine) then I want deletions to immediately write out to disk and therefore to him. So in the current state of things I would have to script that upon deletion the database trash is emptied every time, right? (I feel like the same applies for basically every reason to use indexing in the first place I can think of and read about in this forum, which normally either involves sharing with teammates or having a dual system with some other MD editor for example.)
E.g. consistency (both imported and indexed items work like that) and being able to undo it. One workaround for you might be to use a smart rule which is executed on demand and just uses the action Delete. Then you could immediately delete stuff via e.g. drag & drop onto this smart rule.
Thanks for the hint! Do you happen to have any workaround in mind that works keyboard-only? Or – even better – something automatically detecting trashed items and acting (for example every minute) on that?
With regards to the “consistency”: If I import something, I understand that DT takes care of the file for now but I have to decide what happens with the original. Especially would the original never be deleted upon database trash emptying, so in that regard the consistency point feels a little off to me. Don’t you agree that the use cases that make you index a folder with a loot of stuff in it are usually ones where you never delete the indexed folder but quite often delete stuff within that folder and want this change to be written out to disk immediately? That would to me feel consistent because since we indexed, we gave DT responsibility to synchronize this part of the file system with itself.
I feel like it should be an option. Personally, I even feel like it should be the default. But I understand that the latter is definitely in the realm of opinion. Thanks again for considering.
Obviously I do not The Finder doesn’t delete files immediately and uses its trash, DEVONthink does the same too. No matter whether indexed or imported. And without the trash it’s not possible to undo unintended deletions and just adding the same files again would mean that metadata might be lost, item links might be invalid etc…
A scheduled smart rule could execute a script which checks the trash of all opened databases for indexed items and deletes them.
Thanks. I did not think about the metadata point. That makes sense. So I guess there is just no solution for the problem. Or at least no simple one.
Thanks! Actually I did write a script myself and just now wanted to post it. It is a little shorter since some things your script does I don’t need.
on performSmartRule(theRecords) tell application "DEVONthink 3" set listOfTrashed to children of trash group of inbox repeat with trashedItem in listOfTrashed if indexed of trashedItem is true then delete record trashedItem end if end repeat end tell end performSmartRule
I have this set to execute before sync and it seems to work fine.
(I am using a single-database-approach so everything is under the global inbox – at least for now.)
I deleted mine as you don’t need it and it didn’t take replicants into account.
Note to other readers: Be careful, as mentioned above
delete can not be undone.