Database mysteriously renamed to "Annotations"

Today I realized a database I occasionally use had disappeared from DEVONthink. :anguished:
I then looked in Finder and found its file had disappeared too. :open_mouth:
I was able to restore it from backups, but when I opened the restored version in DEVONthink I got this message:

Internal database identifier (UUID) is identical to the one of another already opened database. Databases shouldn’t be duplicated in the Finder.

This made me look a bit harder at the list of databases in DEVONthink. I noticed an entire database dedicated to “Annotations” :thinking: Sure enough, that’s my missing database.

I can’t find logs going back far enough to tell me what happened here. AFAICT I haven’t lost any data, but it’s such an oddly specific hiccup after years of DT chugging along reliably with occasional use. Any ideas how I can get to the bottom of it?

Do you still use an older version of DEVONthink To Go? And by the way, which version of DEVONthink do you use?

I use DEVONthink 3.9.4 on Mac.

This particular database is only on my Mac – it isn’t synchronized with my phone – but I do use CloudKit to synchronize some of my other databases with DEVONthink To Go 3.7.8 (it would’ve been 3.7.7 at the time the database was renamed.)

Welcome @unarchivist

DEVONthink will not rename or delete your databases without your interaction. If the actual database file (.dtBase2) is missing in the Finder, you should look at what you have running on your machine and retrace your steps to see how you could have removed it.

Thanks!

This is a detail I hadn’t mentioned: the .dtBase2 file wasn’t actually missing. It too had been renamed to Annotations.dtBase2, i.e. the database had been renamed both within DEVONthink and in the filesystem.

From experimentation, it’s hard to explain what’d cause that:

  • Renaming a .dtBase2 file doesn’t cause the database to be renamed in DEVONthink
  • Renaming a database in DEVONthink doesn’t cause its .dtBase2 file to be renamed in the filesystem

That seems to rule out accidental renaming, along with most rogue processes. On top of which, Annotations is a curiously DEVONthink-esque name.

I’d love to, but I can’t find logs going back far enough to work out what steps to retrace.

This apparently happened about two and a half weeks ago, and logs I’ve found (other than critical macOS logs) don’t seem to stretch back quite that far.

As long as the database isn’t damaged (is a verification successful?), the only possibilities are actually AppleScript or File > Database Properties…. But DEVONthink doesn’t log these things.

It does here, though. And I guess also vice versa – the filename without the extension_is_ the database name, afaict.

Actually, changing the filename in the Finder shouldn’t affect the database’s display name in DEVONthink. But changing the display name should change the filename.

Thanks for the info and ideas, all.

@cgrunenberg The database passed verification and a file integrity check.

Ah. This isn’t what I saw when I tested yesterday: I renamed the database back to its original name within DEVONthink but its filename remained Annotations.dtBase2.

I just tried again after verifying the database and now I do see the expected behavior, i.e. the filename is updated when the database is renamed.

The UUID collision had previously occurred in the same session when I tried yesterday, so maybe the normal behavior was interrupted due to that.

So DEVONthink renames the file but not vice versa. This makes a database name change within DEVONthink seem a more likely culprit.

I found ~/Library/Application Support/DEVONthink 3/Console.log which confirms that DT was open for ~30 mins around the time of the name change. (That makes sense. I often open it to reference a paper or other item before closing it again.)

I don’t have any custom scripts (just the defaults) or other automations for DT, and it feels far fetched to blame a cat-walking-across-keyboard style accident, but it seems this is the furthest we can trace things. Something unusual happened in that DT session. Bit odd, but apparently no harm done.