Data loss by rebuilding a database?

I’m trying to get backups of my Devonthink databases into newly acquired cloud storage space. But apparently, there are disturbing issues going on inside my DT dabases; or at least in the first one I chose to get it backed up into the cloud .
I applied the Devonthink command File>Export>Database archive… (not sure about the exact wording, as I use a non-English UI). Devonthink responds: “Zip archiving failed”. Is everything OK with the database? The “Check & Repair” command replies: 14 orphaned files. I press “Repair”. Devonthink tries to repair, but replies: “Repair failed”. The “orphans” folder in the tree view remains empty, interestingly though, the “Orphans” folder inside the dtBase2 package has nine files in it, 3 of them are 0 Byte files. Several 0 Byte files in the Files.noindex structure. Luckily, it was a very small database so I had no problems to find all the files and delete them manually.
Preparing for cloud backups, I thought it might be good idea to Check & Repair, Backup&Optimize and eventually Rebuild another database. I decided to start the latter because there were some records in the database with apparently no content, i.e. DT would only display white space even though the records’ metadata showed that it had a number of words and was a few kBs in size. The rebuild resulted in a substantial number of 100bytes-ish records with no content, and no words. I could recover these records from a quite old external hard-disk backup of the .dtBase2 file. Maybe Time Machine would have helped, too, but I haven’t checked it.
I then had a look inside the other .dtBase2 files and discovered that QuickView didn’t display the content of some mere .txt files. In one instance I couldn’t even open the Settings.plist file. Finder’s info window told me that no one had the right to read or write these files. I applied Mac OS X Disk Tool’s “Check & Repair File Permissions”, but it apparently doesn’t look into packages. Hence the files within the dtBase2 file remained unchanged, i.e. still non-accessible for me. So I changed access permissions of Settings.plist and the Files.noindex folder with the Finder Info window and propagated the permissions to subfolders and -files (I wasn’t sure if Finder propagates permissions from package files to underlying objects, hence I applied that technique inside the package files.).

My current hypothese is that there is/has been an issue with file permissions within the dtBase2 packages. I discovered an issue with file permissions in another database. Apparently, DT, running within the user space and with my access permissions, fails to export the content of some of the files in Files.noindex, while it still manages to create them as 0 Byte files in the temporary export location. That’s my impression acquired by certainly not über-systematic remediation attempts.

So, whichever the cause for this mess, it reveals some omissions of DEVONthink’s Check & Repair/Rebuilt functionality. First, it could detect these 100-ish Bytes and 0 Byte files with no content. Second, DT’s Rebuild could help by detecting issues with permissions, such as the current user having no access rights to files withing the .dtBase2. I know, it shouldn’t happen in the first place, but Computers obviously still have a life of their own. It’s not the first time that I’ve run into a problem rooting in a file permissions issue. DT could be more resilient on this score.

The mess was obviously caused by file permissions set to 000, even though ACLs gave me read/write/execute options. I seemingly had sufficient rights according to the Finder Information window, but devonthink didn’t agree. Setting permissions to 700 or 600 and deleting all the ACL attributes solved the problem. I don’t quite get it, but anyhow, problem solved.
I’d like to suggest that Check & Repair also takes a look at the file permissions and complains if the permission octets of the .dtBase2 file and its contents don’t start with a 6 or 7.

Finder Information window:
MyUserName: Read & Write
Everyone: No access

Output for the ls -le command:
d---------+ 2 AnotherUserOnMyMachine 502 68 24 Mär 2011 2
0: user:MyUserName allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity

Andreas, are you using v2.3.3? I’ve noticed odd, transient incompatibilities and miscommunication between 2.3.3 and Finder. Hard to explain or reproduce, so I’ve not yet filed a bug report. (This is In DEVONthink only - not with Finder and any other app.) So far, I’ve overcome these by having Apple > Force Quit relaunch Finder.

I’m using 2.3.4b1. I didn’t even know that DT communicates with Finder. Well, I haven’t made any attempts to reproduce the error, spent too much time with this anyway and I’m glad it’s gone and I can archive/export the database into zip files. (Which, by the way, Mac OS X’ tool fails to open - “error 63 - file name too long”. Unpacking works with Unarchiver, though.)