Is DEVONThink losing files again?

DEVONthink
1

OK this is annoying. Years ago, DT was massively losing files on me because of extended attributes and filesystem level compression. That was solved, but now…

…2600 files that have been lost. The warning log shows “missing file”, and then when looking up the file, it shows that it is actually missing.

I’m importing them by moving files (.eml) to DevonTHINK’s global inbox folder.

From there, DT picks them up, and through email rules I move them to their final destination.

I know it’s a bit hard to understand at the moment, but I do feel that this could point to a serious bug somewhere with the global inbox.

But not necessarily the inbox - I of course suspect the error being with me somewhere, but then on the other hand, there are mails missing that are from 2019, long time before I crafted my automatic import process.

I’ve also had a crash of the computer occasionally, but would that result in files actually going missing (AFS, Catalina)?

Does DT somewhere log things better than saying, “oops, the file is missing”?

I was switching to DT since Apple Mail was losing mails massively

:frowning:

2

To me it seems, that I have suddenly some warning logs about “missing files” as well, since the Update to 3.5.1, I guess.

3

Yep, but those files are actually gone. Like I see an email communication thread, and in the middle, one is missing.

4

If Apple Mail is “losing files massively” and your computer is crashing, it sounds like you may have operating system or hardware issues. And yes, hardware issues can cause data loss, not only in DEVONthink but elsewhere. Have you had this machine serviced? If not, I would suggest it just to see where it’s at health-wise.

5

Machine is working happily along. I’ve just had a random reboot a couple times when I was too bored to wait for some runaway process to give back resources. So far, this should have been caught by file system journalling.

6

Filesystem journaling can’t ensure that the database and the filesystem are consistent, therefore this might indeed be the result of the system crash.

And since version 3.5 databases are automatically verified if they were not closed properly (e.g. due to a crash), therefore the only difference is now that it’s much more likely that you’ll notice the issue at all.

7

Thanks Christian.

How can I remove those stale entries, since the files are no longer there anyway?

Also, does that mean it would be preferable to close DT if not in use?

8

E.g. verify the database, then select the entries in the Log panel/popover and use the contextual menu to move them to the trash. Afterwards empty the trash. By the way, were the items imported or indexed files?

No. But a good backup strategy (e.g. not only one Time Machine) is always highly recommended, e.g. in case that a system crash, power outage or hardware issue should cause real troubles.