Unindexing a folder

What i do is when I know that I need to delete items from an indexed DB, I make sure to clean the DT internal trash before that and only then delete items from that indexed DB. In that case DT always asks if I want to delete stuff only from within DB and/or on the filesystem from the trash and I am confident I am not deleting anything else I do not want to delete. This works for me so far.

But still, from user perspective, I find this behaviour really not user friendly and still believe that to make this feature safe, DT shall integrate a proper unindex functionality to make sure people do not lose data when indexing (and there are a number of cases where indexing is the only way e.g. sharing data with other applications like obsidian).

1 Like

I support this 100% to make it more intuitive.

When you focus on work you cannot always remember special behavoius of every program - especially when it’s a most natural common task like drag and drop of “files”.

When you don’t empty the trash immediately you won’t remember what you might have done some days before.

At least it would be helpful to have this dialog box directly when you take action and not later when empty the trash.

The next release will improve the alert in case of indexed items in the trash which are located in enclosing indexed folders and which would be automatically deleted like imported items.

2 Likes

Do you mean the alert when emptying the trash ?
This would be really nice to have but better would be a dialog at the time when I move something to trash.

You don’t want to / can’t recap what to do again when you just want to cleanup the trash.
Its a decision you have to make when deleting a folder.

Maybe a solution could be to exclude the trash functionality for indexed folders at all?

The new alert will actually offer an option to skip the trashed indexed items.

I am revisiting this thread because I would like to have this too.

Currently, when we want to delete an indexed item, we have to move it to the Trash in DEVONthink, but the actual file is still in the folder on the hard drive. And it will stay there until we empty the trash.

I dislike having to empty the trash in order for the file to go away.

Would it be possible to exclude the trash functionality for indexed items as @Andreas76 suggests?
Maybe they could simply go to the macOS trash instead of DEVONthink’s trash.

This is a data-safety priority no different than the system Trash. When you delete a file in the Finder, it goes into the system Trash until you empty it. It doesn’t immediately remove the file (unless you’re messing about in the shell… and don’t!) DEVONthink follows suit to help keep people from mishaps with their files.

1 Like

Can there be a smart rule which will automatically check DT trash and offer to delete „deleted“ (in DT) indexed folders ? And only those.

No a smart rule wouldn’t work because the Trash isn’t an accessible location to target.

Why would you want this when you can easily choose DEVONthink 3 > Empty Trash or press Shift-Command-Delete routinely?

1 Like

Thanks for responding, @BLUEFROG .

When you delete a file in the Finder , it goes into the system Trash until you empty it.

But there is a difference between what Finder does and what DEVONthink does.
When I delete an indexed file or folder in DEVONthink, the file/folder immediately disappears only from DEVONthink but it’s still there in the filesystem.

And this is problematic: DEVONthink is providing an incorrect representation of what the filesystem looks like.
And it’s cumbersome having to delete a file/folder twice in DEVONthink to make it go away: once in the indexed folder and again from the Trash.

It would be better to immediately remove the file/folder in the filesystem when deleting in DEVONthink and possibly make it possible to bring it back by restoring it from the Trash.

Could this not be achieved?

I think DEVONthink really should give a real representation of what the filesystem looks like.

This would be very bad form and I wouldn’t want to see the huge influx of support tickets asking why this is happening.

The behavior in DEVONthink is no different than in the Finder. When you move a file to the Trash, it is not immediately deleted. It is incumbent on you, the user, to routinely empty the system Trash.
Would you suggest Apple adopt the behavior you’re suggesting, where files immediately vanish instead of going to the Trash, forcing the individual to go to their backups to retrieve files they trashed, even accidentally?

To make sure I explain my idea properly, what I mean is that, in my opinion, when a user would delete an indexed file or folder, it would still go into DEVONthink’s Trash or macOS trash.
And if the user wants to recover it, it could still be restored from the trash.

That’s how the Finder behaves. A deleted file disappears from where it was and goes to the trash.

But DEVONthink’s behaviour on this is different. DEVONthink isn’t moving the file to the Trash like the Finder does. I mean, within DEVONthink, it moves it, but the file is still in the same location on the filesystem.

It’s like the Trash in DEVONthink isn’t really storing deleted indexed files and groups, but instead storing “instructions” to delete them.
It’s like the user creates the “delete instruction” when he/she deletes the file/group in DEVONthink, but then has to ensure the “instruction” actually executes by emptying the trash.

It’s a 2-step process that is not very intuitive, as @Andreas76 also pointed out.
It also has the downside of turning out to be misleading because it means DEVONthink doesn’t always provide an accurate representation of the filesystem.

Well, that’s quite correct as DEVONthink isn’t storing the files in any location in your database. As has been said many times before, DEVONthink is a database; it’s not a filesystem.

If you’re wanting to have “an accurate representation of the filesystem.”, why not just do your file management in the Finder?

Remember: DEVONthink is not the Finder, nor is it merely a front-end to your Finder. And there are sound reasons why indexing is not the default behavior for getting data into your databases. Reading and understanding the interactions with the Finder should be the first step before committing to indexing.

One of the questions was about unindexing files and folders.

It seems to me that if I delete an indexed group in Devonthink, it doesn’t delete it on the disk. If I then drag the folder into Devonthink, importing it, I’ve done the same thing as unindexing it.

Backup copies of the files in flight aren’t a bad idea for such maneuvers.

I disagree. (At the risk of putting words in the mouths of the DT developers) The location of a file in the file system is not a component of the façade that DT creates. Based on your suggested model if I move a file from one group to another, the location in the file system should change (and more importantly I should actually care about that — which I don’t) The trash in DEVONThink is part of the DEVONThink overlay and like all of the other parts of the DEVONThink overlay it doesn’t provide any transparency into the file system that underpins it — other than that you can find out where the file is in the file system. So, bottom line, I think that what you are suggesting would actually pervert the DEVONThink model rather than provide clarity.

Just my two cents.

1 Like

First of all, my bad that I didn’t learn more about mechanics of Indexing before I use it (on some very important files/folders).

So, I’ve read this thread, but just to be 100% on safe side: once you’ve indexed some folder structure in Devon, if you want to “un-index it”, you can do it, but for the rest of the life you must make sure not do delete indexed items from trash upon Empty Trash operation ?

OK, let me reply to self :smiley: … and where the confusion came from:

In order to get this:

image

you need to do Empty Trash on the main trash, not Trash of particular database (which I was trying to do)

That is incorrect. The warning message depends on what indexed item you put in the Trash. That is discussed in the Help.

Thanks for heads up on my wrong conclusion. I see the https://download.devontechnologies.com/download/devonthink/3.9.5/DEVONthink%20Manual.pdf pg.55/56 where it’s explained the two different dialogs.

You’re welcome! :slight_smile: