My 3 databases are encrypted on DEVONthink, which means that their size is restricted on Mac.
One of them got fill up too much from an iPad, which does not have that restriction. So, the remote sync location was too large for DEVONthink on Mac.
I think this corrupted the datbase and somehow this got mirrored back to the sync location and from there back to the iDevices.
I deleted the iPad, made a new and larger encrypted database on DEVONthink and moved the olde4 content from the bad into the new encrypted database.
Then I synced this back to the remote location, deleted DTTG from an iPad and one by one added all databases back, inbetween testing if searching for tags works again.
It seems to be OK now.
I only need to repeat on the other iDevices.
Encrypted databases that are too small for a remote sync location seem to be a source of corruption!
A bit off topic, but I was wondering about the reason you are using encrypted databases. Shared Mac? Unencrypted external drive?
In my case, FileVault is enabled and encrypts everything and as long as a sync password is used, the data stays encrypted in the cloud/sync service of choice as well.
I don’t trust Apple and read several negative comments about FileVault, also I like to have an easy way to backup or archive versions without needed to encrypt them again - DT already offers this out of the box, so why not use it?
I see. I think the encryption is the same though, both options (FileVault and encrypted disk images) are provided by Apple (someone correct me if I’m wrong, please).
There are some advantages to FileVault though, metadata like Spotlight would be encrypted as well, whereas encrypted disk images only protect your DT files.
Of course, I also have FileVault enabled.
But that may not help, when remote access is enabled and in some other cases too.
Therefor, I prefer the additional encryption.
And, as I wrote, this allows to easily archive and backup images to other storage, incl. cloud storage.
So, why should I NOT use it?!?
Encrypted databases are indeed a handy thing to use, regardless if you are using a full disk encryption method as well.
The one thing to be cautious about, as found by @tja, is the size of such a database is fixed - as it’s actually a database housed in an encrypted disk image - and this can lead to the issue reported.
Otherwise, there are plenty of scenarios where an encrypted disk image may be desirable, especially because the database is portable.
I personally have a slightly different workflow that probably wouldn’t profit from additionally encrypted disk images, since I only use fully encrypted external drives for backups (Time Machine and CCC) and my cloud backup is encrypted by the app itself (Arq).
But I guess using something like Dropbox for archived databases makes it much more useful to use additional disk image encryption, in addition to having images unmounted in case of remote access.
…so long as you trust Arq’s implementation of encryption. I have no reason not to. But also no reason to trust it. So I use encrypted databases too; that way I can be sure they will never leave my Mac unencrypted. Assuming I trust Apple’s implementation of encryption, of course.
Good point. Given the excessive Disk Utility bugs in Catalina and Big Sur though, and some rather bad experiences before that with encrypted images (sparsebundles though), I’m not sure what to trust any longer.
