How do I safely manage indexed files?

[mmynsted]

I have found that I have on occasion, accedentially deleted indexed files from their original finder location when my intention was to simply remove the index from DT. I wish to use the power of indexing, but prevent myself from deleting the original files.

My understanding is that it is possible to remove the index from DT without removing the original source by removing the top-most indexed item.

Group/Folder based indexing

If I have the following folder structure and wish to index all the files under folder A. I can index files and folders by selecting A as my source for indexing. See (1).

Once this path is indexed, if I find that I do not want to index sub-1, see (2), and remove it from DT, it will also remove the original files like f4.0, f5.0, as well as the original sub-1.

If all I want are the files in B (3), then I simply index B and I get all the files from that folder. If I remove B from DT then the original files are kept safe.

Individual files

If I index an individual file and later do not want it indexed. I think I can remove it from DT without it being removed from the original location. The problem is that it is unlcear how to know the file is individually indexed once it is replicated to useful locations in DT.

Solutions for Management?

I heard Rosemary Orchard mention that she keeps all her indexed files and groups in an Indexed, top-level group. So far this seems like the best way I can think of to be able to identify the top level index. What I mean is being able to differentiate between an indexed group like (1) from (2). Then replicate the files and groups around as needed. Then only deleting the top level index from the indexed group.

Is there a property or something that identifies a top level indexed item? I would like to run a script or something to change the group and file icons of all the top level indexed items so I can easily differentiate between top level index items and other indexed items even after they are replicated to many locations in DT.

Questions

• Is my understanding of un-indexing indexed items correct?
• Are there orther ideas for managing indexed items, different from the one described by Rosemary Orchard?
• Is there a property automatically set when files and folders are indexed to identify a top level index?

Here are some related links I have read:

• Suggestion: preference setting to block any possibility of deleting indexed files (“never delete indexed files” checkbox)
• Script: Finding the true parents for the lost children (misplaced indexed files and indexed groups)

[rufus123]

How about creating aliases of files to index and allow DevonThink to index aliases ? If by mistake, you delete an alias, it not a major problem.

[mmynsted]

That is a good idea. I had not thought of that. I could alias or symlink all the files I want to index to a common location outside of DEVONthink. Then, if this works, I could not worry about deletion from DEVONthink.

I wonder if there is a way I could alter the exiting index process to do this automatically. . .

[rufus123]

that does not seem possible.

If you select a file in Finder → create an alias → open DevonThink→ File → Index Files and Folders→ go to the folder where the alias you created is located, you notice 2 things
1- the alias is greyed out
2- strange : you are able to select the alias despite being greyed and and the file represented by the alias appears in DevonThink. The question is what is this document in DevonThink? I don’t think that it’s an index of anything (neither alias not original file). I suspect that perhaps DevonThink imported the file (how, I have no idea). I suspect this because if I delete the file in DevonThink, I see no question or warning dialog about a file being deleted in Finder.

If you have time, I would be grateful if you could test this on your own computer and see if you can understand what is going on.

thank you

[BLUEFROG]

My understanding is that it is possible to remove the index from DT without removing the original source by removing the top-most indexed item.

Yes, that is correct. (We usually call the top-most indexed item, the indexed parent.)

---

Aliasing is not the advocated approach here.

It is almost always a better approach to index individual parent groups instead of a main parent folder. Not only does this keep excess data out of the database, it also allows for the potential to unindex a group from a database.

In your example of the sub-1 group, no you can’t unindex it. If you have indexed parent A, everything inside it will be indexed as well.

[mmynsted]

@rufus123

If you have time, I would be grateful if you could test this on your own computer and see if you can understand what is going on.

Sure.

It appears that DEVONthink follows the alias to the original file. The result seems to be the same as if I had indexed the original.

Make alias to B

Index alias to B

Un-index f2 by sending the indexed item to the trash

Select Remove All Items from the trash

The original f2.0 files has been removed from the filesystem, in addition to the index in DEVONthink

[mmynsted]

Okay, then I am back to finding a way to differentiate indexed items from indexed parent items.

It does not appear there is a built-in way to do this. Maybe some automation is in order?

I Want to Create an Automation to Help me Differentiate between Indexed and Indexed Parent Items

[rufus123]

sorry for the delay. Problems with a new Mac. I notice that the dialog box does not ask if you really want to delete indexed items, which suggests to me that there are none.

[cgrunenberg]

@mmynsted

Index alias to B

Aliases & symbolic links are resolved while importing/indexing.

[stuartro]

Is there any possibility of having DT visually differentiate between indexed and non-indexed files (e.g. use a different colour for the folder and file names, or use a different icon / adornment on the existing group icon)? I recently ran into the accidental file deletion problem twice (and was saved when I saw in Git, which I use to manage “external” (to DT) files.

[chrillek]

There already is an icon. See “Iconography” in the manual.

[stuartro]

Indeed there is . I must be getting old (or need a new pair of glasses). Thanks @chrillek.