Hello, all.
Currently, when an indexed file is moved to the trash in DEVONthink, nothing actually happens to the file in the Finder.
The file will not be deleted until I empty the trash in DEVONthink and confirm that I want to delete indexed files.
Although this behaviour can be confusing at first - it was for me and I have seen posts from other users about this - once I understood it, it made sense to me why a file does not get deleted immediately.
However, I believe there is a good improvement that could be made to this.
In Finder it’s impossible to distinguish any files which have been deleted in DEVONthink (moved to the trash).
Having visibility on this would be very useful. I would like to be able to open a folder and be able to spot any files in there that don’t matter because they are in DEVONthink’s trash. That could even act as a reminder that it’s time to empty the trash in DEVONthink.
So here’s my suggestion:
When a file is moved to the trash in DEVONthink, the name of the underlying file would be modified by adding the prefix “DELETED_”. So if the file is “Guide.pdf”, it would be renamed to “DELETED_Guide.pdf”.
(Note that the name of the item in DEVONthink does not need to change - only the underlying file in the disk.)
An even better prefix would be “DELETED_YYYY-MM-DD_HH:MM”, where the timestamp corresponds to when it was deleted.
This prevents name collisions in scenarios when multiple files with the same name are iteratively created and deleted. (This happens to me a lot when I clip a page as PDF to DEVONthink multiple times until it is saved properly).
I do not want to have to empty the trash every time I move a file there. We don’t do it with the operating system trash either, because:
It’s inconvenient - deleting a file would require 2 steps;
It would add mental overhead, because I would also have to remember to do it every time;
It would defeat one of the main purposes of having a trash, which is to recover files if later you realise you deleted the wrong ones.
There is nothing wrong with only emptying the trash after weeks (contrary to trash bins in the real world ).
So until that moment comes, I would like the filesystem to show me that something has been deleted in DEVONthink.
However, it would be even better if this becomes the default behaviour.
The intricacies around the deletion indexed files are not obvious and therefore it has been a source of confusion on users.
I believe that this confusion would be greatly reduced or eliminated if this was the default behaviour.
Just because this idea makes sense to you that doesn’t mean it makes sense to other people I don’t want my files renamed unless I do it manually or explicitly instruct a process to do so.
Why don’t you just delete them through Finder?
What files are you indexing? Why are you managing them through both DEVONthink and Finder? I think it’s better to choose a primary interface to manage them—that avoids confusion, especially if you want things to sit in the trash for weeks.
It does takes up unnecessary space on your hard drive, though. I personally empty the trash at least daily. Just right click the trash in the dock and choose empty trash, pretty quick. Most launchers also have an Empty Trash command. (I use Raycast at the moment)
We might consider this if there’s a common interest but so far it’s the only request of its kind and I’m sure a lot of people wouldn’t like it (e.g. me ). In the end it will be possible via a simple smart rule.
Not at all. But the point is you still deleted it. How often do you go through the trash, or indexed files you already wanted gone, and analyze their contents? No offense, but this “feature” request is useless to me—and I’d guess 99% of other users.
DEVONthink has many particular behaviours, which aren’t obvious and easy to grasp. The deletion of indexed files is one of those.
I assume that everyone who contributed to this conversation already has a good understanding of how it works.
Nowadays, I understand how that works too, but until I did, it was a source of confusion. Files that I had trashed in DEVONthink were still visible in the file system when I used Finder and I couldn’t understand why.
Therefore, and to be honest, I’m submitting this change request not so much for me, but instead I’m thinking of other users who don’t understand this yet and get confused about it.
Additionally, in my opinion the problem is aggravated by the lack of a feature to un-index an indexed parent folder. When a user wants to un-index a folder, they have to trash it and select the correct option when emptying the trash. When users don’t yet grasp all these intricacies around management of indexed files, they are very likely to do the wrong thing and lose data.
In response to those who mentioned that they wouldn’t want this change, I would ask: would it cause any inconvenience to your workflow? Or would it, actually, make no difference to you simply because you don’t need it?
If it would bring you any inconvenience, I would be curious to know more.
For new users, I believe this would be beneficial, and potentially could be what prevents them from messing up and losing data.
I always empty the trash immediately after deleting something. Otherwise, I find it just too risky or confusing. When the trash has a mix of things (folders, files, indexed, unindexed), I don’t know what will happen when it’s emptied since the popup dialog can be misleading or erroneous (per my post that was referenced). Emptying the trash quickly prevents complexities from arising.
I would benefit from what @luisneto is recommending. It is not the case the DEVONthink is my only interface to the content. I would like a clear indication that the file is marked for deletion by DEVONthink and not feel pressured to empty the trash right away.
This was less important up till a short while ago. I used to use DEVONthink To Go to access content on my iPhone and iPad. I’ve recently abandoned it for a few reasons. I now access the indexed content on those devices using the Files app.
Having retrieved something from the trash just this week, I think there are advantages to both positions.
While it’s true that backups provide more robust protection, it’s also true that finding a single document in a backup (or possibly multiple backups) of a large database can be challenging.
Retrieving something from trash is one thing. I’ve done it too. What OP is suggesting is quite another. And I’m certain that less than one half of one percent of anyone on the planet goes back to analyze the month, date, or year of a deleted file, much less the exact time it was deleted. This is something absolutely no one wants or needs.
And if you really want to be pedantic about it, sure, it’s not that no one would want this feature. That was not my point. My point was the vast majority of users have no use for it. Clear enough?
I’m certain that less than one half of one percent of anyone on the planet goes back to analyze the month, date, or year of a deleted file, much less the exact time it was deleted.
This is not about analysing deletion dates. The inclusion of the deletion timestamp is to avoid name collisions.
Call it a fair assumption.
The fact that nobody has had this idea before does not mean you can assume that. All ideas start from someone.
This is not about having a feature that allows users to do new things. It’s a change to give users more visibility / transparency on a non-obvious behaviour that has been a source of confusion. It’s a change to proactively reduce that confusion.
).
I don’t want my files renamed unless I do it manually or explicitly instruct a process to do so.
). In the end it will be possible via a simple smart rule.