Read-only database

DEVONthink Tips
1

Specs: OS X 10.11.3; DTPO 2.8.9

My macbook appears to have crashed overnight, and re-started. First up, there was the usual message about databases being in use. I’ve alway found that a little irritating, as I only use DTPO on one machine. However, minor complaint.

At the time of the crash, I had 6 or 7 different databases open. On previous occasions, I was able to simply click continue on each individal ‘database in use’ message, and everything would open fine. This time around I received a message saying that there were two serious inconsistencies in a database, advising me to rebuild. I selected the rebuild option.

Problem 1: I was not told which database had issues. Reading the log window identifies the affected database. Running verify and repair on that database reports no problems. However, before choosing whether to ignore the reported problems, restore from back up or rebuild, I would like to identify the database. This would help inform my decision.
Problem 2: I now have a different database which has the pencil with a line through it (making an x) appearing in the side panel. I am presuming this means it is read-only. Certainly I cannot add or delete items from the database. In the database properties window, the Read-only box is not selected, and greyed out. I seem to remember deleting a lock file in a similar situation previously, but have forgotten how that is done. From the manual: ‘Read only databases are marked with a read-only icon’. No explanation of how to undo this; the intuitive thing to do is to uncheck the relevant box in the properties window but, as noted above, that is currently unchecked.

I’ve previously mentioned on this forum that I find the DTPO manual to be somewhat lacking. I’m re-iterating that point here, because I am not able to find anything in the manual to adequately to explain the read-only icon. There is a table of icons in the Sidebar section of the manual, and of course in the Iconology appendix. This icon seems to appear in neither, which is odd.

All of which is a long way of saying that I would like to be able to remove the read-only restriction in the affected database. Can somebody please remind me how to delete a lock file, if this is indeed the correct way to go?

I have also filed a support ticket with the above information, but as this is the weekend and I’m not sure how likely a response is before Monday, I’m posting here.
Thanks,
Kinsey

2

Quit DEVONthink. Navigate to your database in Finder. Select it and open Finder > Get Info. At the bottom of the Info panel, disclose the Permissions section. Make sure your account has Read & Write permission.

If your machine crashed you need to find out why. What happened to DEVONthink is just an unfortunate by product. If Finder’s Get Info does not appear to show anything wrong with the permissions, then shut down all apps and boot into the Recovery partition to repair permissions. If you are running El Capitan then look up the procedure. This only is a band aid. You need to find help for the root cause of the machine failure.

3

Thanks for the guidelines Korm, will check back if that doesn’t resolve the issue. And thanks also for the advice re investigating the root cause of the machine crash. My machine has been affected by the trackpad freeze issue, which causes the screen to go black. This has been so infrequent that I am unable to reproduce the cause; also I don’t think this is related to the machine crash.

4

Just to update. Permissions are set to Read and Write on the affected database. Verify and Repair returned the following message on the database before quitting DTPO: Found 0 inconsistencies, 0 incorrect checksums, 0 missing and 0 orphaned files. Strange.

Upon restart, Initial Verification is giving the following message for that database: Found 2 major file errors. Please restore the last backup or rebuild the database and verify the contents afterwards! At least I think it’s that database; the verification message does not identify the database, but the loading bar on the start up window (for want of a better term) is stuck on the database that I thought was read-only.

I am in touch with Devontechnologies support now, so hopefully will get things resolved soon.

5

Good luck.

A database is nothing but a folder of files, any one of which can be corrupted by disk errors and cause a kernel panic and shut down.

6

Thanks Korm. I was never really worried about data loss, as I employ a rigorous back up policy.

I eventually rebuilt the database. I must say that this was a less than satisfactory experience. Having quit and restarted DTPO twice, each restart prompted the same error message (Found 2 major file errors. Please restore the last backup or rebuild the database and verify the contents afterwards), but when I restored from back up, DTPO restored a different db every time. Contrary to my last post, though the start up window was frozen on the load bar of the problem db, a different db was restored.

So I quit again and restarted. A third, different, db was restored from backup. I did not know which one it would be until the log told me. After each restart, the problem db remained read-only, and Verify and Repair gave me the ‘Found 0 inconsistencies, 0 incorrect checksums, 0 missing and 0 orphaned files’ message. On the fourth quit/restart, I selected rebuild, even though I still did not know which database was at issue. On this occasion, the problem read-only database was rebuilt (after returning a very disconcerting message that 150,000 or so inconsistencies were found).

After this rebuild, all issues seem to be resolved. I am now going to go through backups to make sure that the db, as rebuilt, is in fact intact.

My experience suggests that DTPO’s problem reporting mechanism on start-up is flawed. There is no indication as to which db is affected. If I had known which db was being referred to, perhaps I would have selected a different option (rebuild rather than restore from backup, etc). More importantly, three of my dbs were restored/rebuilt even though, prior to quitting, all three returned no issues on a Verify and Repair. Which brings me back to the original point - I should be told which dbs are going to be rebuilt/restored, rather than operating blind, as it were. Also, I am now less inclined to trust Verify and Repair. Perhaps that’s an over reaction; I have been using DTPO happily for almost 4 years now, and have only ever had minor problems before. DTPO is an integral part of my work flow at this point.

Perhaps Devontech might consider better implementation of the reporting feature to avoid similar situations?

7

Did you use Tools > Restore Backup, or did you “restore” from your own external backup?

When DEVONthink does a “backup” what it is doing is putting a copy of your metadata (but not your documents) into a file kept inside that database package. Tools > Restore Backup merely restores the backup copy. You’re offered a choice of data depending on how many backups exist.

So the business about “restored a different [database]” makes me wonder. Have you by chance renamed a database inside DEVONthink (Database Properties) but not renamed the physical database .dtBase2 package in the file system? Or, did you happen at some point duplicate a .dtBase2 package and give the duplicate a different name? (Duplicating .dtBase2 packages can result in strange things and confusion on DEVONthink’s part.)

8

Sorry Korm, I don’t think I was precise enough in my terminology. When I refer to a different db being restored each time, I mean a different physical database. So I had four databases open (let’s call them DB 1 through DB 4). Upon first restart I got the start up verification error message described above, and chose to restore from back up. First restart restored DB 1. Second restart, same message and process; DB 2 was restored. And a third time; DB 3 was restored. So I wasn’t restoring different versions of the same database each time, but discrete databases. Hope that makes sense.

I also should note that I did not use the Tools-> Restore Backup or Tools->Rebuild Database commands. I was following DTPO’s start up verification prompts. That gives the options to Ignore; Restore from Backup; or Rebuild.

On the fourth restart I opted to Rebuild, as Restore from Backup was not resolving the start up verification issue (and DTPO seemed to think that all the databases needed to be restored, even though Verify and Repair returned no issues before quitting). I honestly didn’t know what database was going to be rebuilt. It turned out to be the read-only database.

After the rebuild I had no permissions issues. I zipped the rebuilt database and copied the .dtBase2 file to an external location. I then deleted it from the directory and restored the most recent pre-crash back up from Time Machine. It showed that I had suffered no data loss. Up to that point I had never duplicated a database and have never knowingly renamed a database. I’m glad to say that the backup advice re DTPO that I have read here on the forum, and in other online locations, has proved to be robust. I would say that I follow about 99% of the distinction between the backups of metadata that DTPO performs, and the necessity to back up documents/files in another fashion :smiley:

The end result is that the rebuild was successful. I have restarted a couple of times, and received no start up verification errors. I use indexing extensively, and am glad to report that the structure of the databases all seem to be intact, with no missing files or broken index links. So, I am very satisfied with the rebuild tool of the database. It works well and quickly. The rebuilt database is 11.5GB in size, with 1.5million words and took less than 5 minutes to rebuild.

If I have a frustration, it’s that the start-up verification notification does not identify the problematic database(s).

Thanks for taking the time to respond/advise so far Korm, much appreciated.

9

Got it.

I think there’s still something broken, but Support will be able to advise.

10

Hope so :smiley: . Bill responded very quickly last night, I’m sure we’ll continue the conversation tomorrow.
Thanks again.