Can I safely stop an Index in progress on a large external hard drive?

Hi - I just learned a big lesson last night about Indexing files. I wanted to index all of my external harddrives for reference purposes only, and I learned a few hard lessons. I didn’t realize the tight integration with Finder (e.g. if I delete the indexed files in DT, it will delete in Finder as well; if I move the sub-folders in DT, it actually moves them as well in Finder and seems to create a cloned folder with ‘-1’ after the name).

In any event, I have 1 very large harddrive left here that it’s still indexing and it’s been going on for about 13 hours or so now (and only halfway done). I want to safely stop it completely and not have it index anymore. What is the best way to do this if even possible? Or do I need to let it finish? I’m more than happy to also completely remove it from DT altogether and I won’t index in this type of way anymore, but I don’t want to mess up anything further with what I’ve done so far :upside_down_face: I appreciate any help and feedback! Thanks.

Yes, I would let it finish, just to be safe. And indeed, what you were trying is not recommended. Indexing must be thoughtfully considered and understood, hence it’s not the primary vector for getting your data into DEVONthink. People should read and understand the In & Out > Importing & Indexing section of the built-in Help and manual before committing to indexing.

1 Like

Thank you for the quick response. I’ll let it finish. I just hope my Drobo doesn’t die in the process as I’m in data recovery mode right now (moving it to a Synology) and thought indexing the drive would be “smart” to know all the files I had on it :upside_down_face: oops :upside_down_face: I’m not doing myself any favors here.

Thank you again and for the link

You’re welcome :slight_smile:

It’s a common misconception that DEVONthink is a Finder or Spotlight replacement. Here’s an oldie but a goodie…


Hi - I have a follow-up question if I may. The good news is that I safely retrieved all data from my Drobo and safely migrated it to Synology :slight_smile: :four_leaf_clover:

For this database I created to index external drives (big lesson learned in what not to use Indexing for) - so long as I don’t have that database open in DT at all, can I just safely delete the database file from Finder on my mac (and empty trash) and I won’t “lose” any data upon a subsequent open of the DT software? Is that a “smart” way to correct the “dumb” error of my ways? :upside_down_face: Just delete the db file itself in Finder as shown below?


(It’s okay - I don’t mind calling myself dumb)

The reason I’m asking is that DT keeps “crashing” when I try to open this DB. The good thing is that DT does not open all my previously open DBs when it crashes (i.e. not responding) and I re-open it, so was thinking I could just safely delete the database itself in Finder (if that makes sense). And then open DT as normal and move on …

I appreciate any advice! Thanks.

If you’re indexing data, the files are not inside the database. So yes, you can delete it. I would also empty the system Trash and reboot the machine before proceeding.

1 Like

Great - thank you again so much! I appreciate it.

You’re welcome.

I recommend creating two smart rules for each database containing indexed items: one with “Kind is Any Document” and “Item is Indexed”, and a second one for “Kind is Any Document” and “Item is not Indexed”.

This way, you automatically know if you have non-indexed items because some operations in indexed items could create non-indexed items, like summary creation, extraction of annotations if you do them out of an indexed folder containing indexed folders. It is not the first time I’ve lost documents (*) because of this reason when deleting or messing with databases.

(*) Well, not really lost because I have copy of all, but risk to lose them.


Thanks for that - I think I maintain completely separate databases for Indexed vs. non-Indexed items (e.g. I always put ‘(Indexed)’ in the database names), but I could see myself making a mistake somewhere. These are handy rules to make sure that is the case! Much appreciated.

1 Like