Dang, that’s really unfortunate and disappointing to hear. 
I don’t think anyone’s harmed by it, since you’ve moved on. EagleFiler has a different manual crash rebuild/verification workflow but neither it nor DT need it most of the time.
1 Like
The warnings are in your best interest. But as @cornchip says, as you moved on it does not matter.
1 Like
Just trying to slip in a warning for new users or those considering a move to DT. (Obviously, I know that I am no longer affected. C’mon, guys!)
4 Likes
Yes, sorry, of course you do know and I didn’t say that well. I just meant that for people who like DT’s philosophy, the non-closed database warning after a crash is just one more thing it does right. People who don’t like DT would be the ones that see that warning as just another paper cut. DT and EagleFiler both do a great job recovering from system crashes under the hood.
We benefit from the whole spectrum of opinions here about every piece of software in the Apple ecosystem here, for sure.
2 Likes
I don’t think it was the issue itself as much as it was Support/Devs being pretty aloof about it and users kind of having to “prove” there was an issue. Very relevant when archiving years of data. See current discussion.
2 Likes
Database software has traditionally been subject to open/closed file issues. No software is perfect, but with DEVONthink, I’ve long been waiting for an advance like this feature claimed by the in-memory database Panorama X. After all, the Finder doesn’t lose data on a crash. Neither does BBEdit, just to name a couple of notable examples.
Total Recall Auto-Save/Crash Recovery - Panorama X - PDF page 66
FWIW, I managed an email server for 14 years or so that stored all mail in MBOX/sliced MBOX files. In fact the entire datastore was plain text files, it used no databases. It was the most reliable server I ever used. We never had a single software or file problem.
2 Likes
DT isn’t losing data in these situations. It’s just scrupulous about warning you that you are entering a situation where data loss could occur (two computers using a one database) or could have occurred (the computer crashed in the middle of saving the file you were using.)
It’s the scrupulousness and particularity in DT’s UX that rubs people the wrong way, not the performance-durability-replicability tradeoffs it makes.
The recent advances in conflict-free replicated data are promising and will be changing what those tradeoffs look like as they mature work their way through legacy software. That’ll be a better fit for DT’s data than something like a write-ahead log in a traditional database or Finder’s lower performance durability that doesn’t really handle multi-user/multi-process conflicts.
2 Likes
No this behavior hasn’t changed and it’s not something to ignore.
If your machine or DEVONthink has terminated abnormally, it should be looked into.
This also goes for why you’d force quit the application.
And the warning is to let you know, something unexpected happened, so you should be aware of it.
2 Likes
A warning about what specifically? That DEVONthink is diligent in letting people know something has gone awry and potentially has affected the data? Note: potentially.
We not only consider it good form to alert the user, we also want them to be thinking about, *“Oh yeah, the thunderstorm knocked out the power last night! I hope that didn’t cause any issues!”, etc.
PS: Upon reopening database, DEVONthink does a verification to determine if there is any detected damage or inconsistencies in the database. If there are, you’ll be prompted and Window > Log should report in more detail.
2 Likes
I get everything you said. But for all the years I’ve used or watched DT, I’ve kept hoping that this recovery process would be improved to give ordinary users more confidence in the safety of their data.
2 Likes
A warning about an inability to positively and confidently deal with what is an all too often occurrence. This frustrating behavior was what pushed me to eventually quit the app when v3 came out. If nothing else, the UI could be improved to give more detail so that a user better understands what has happened.
I think you simply did not understand the working mechanism behind those messages.
If you open a Database, there is a little “1” (or similar sign) written into this database, that means this database is currently in active use by a user.
If you now open the same database, you will get the warning, as the “1” is still in the database.
You shouldn´t use the same database on two different computer at the same time, as it won’t be possible to guarantee that all you change in the database on one computer, will still be there, if you close the database on the other computer, as it is highly possible, that those data will be overwritten.
That is the purpose of the warning.
If you close your database, the “1” will be removed from the database again, and you could open the Database with DT without getting the warning.
If your system crashes (or you just switch it of, or run your battery on empty), the “1” will not be removed, because the database was not properly closed, and you will get the warning the next time, which in this case should also trigger a check of the database, as a crash could leave some damage to all kind of data, that is currently written at that time.
I didn´t had that warning now in years, so not a big deal at all…
This is, as far as I remember, also written in detail in the documentation.
1 Like
with what is an all too often occurrence.
If DEVONthink was crashing or stalling, it should be reported to us via our support ticket system. Other machine crashes are beyond our control and we can’t say “what happened”. Did you report crashes or stalls?
1 Like
I spent some time this morning looking in the PDF of the DEVONthink v3.9 Documentation as well as the latest Take Control e-book and was not able to find a mention of the database “seems to be already in use” error message. I did find many references in DT’s Discourse forum. The “already in use” error seems to have been a pain point over the years, even up to the present time. Even though I was a solo user with a single Mac, this error message never seemed to get any smarter. It was a bit frustrating when I took advantage of the ability to keep multiple databases open and all reported the same rather non-specific error after a problem restart. I had an extensive collection of data in DT v2 and trialed v3, but decided against continuing, exporting my data back to a structured set of Finder folders at that time.
What more information would you expect to be shown in this prompt?
There are two conditions here:
- Someone had the database open already
- The database wasn’t closed properly, either via a Force Quit or crash.
Then it tells you to press the Continue button if you’re sure no one else has it open.
And as I mentioned earlier, DEVONthink 3 does a verification of the database upon opening and provides more information about any issues it finds. That is indeed “more information” than was previously given in the 2.x line.
3 Likes
Why/How should it get any “smarter”?
What are you expecting from this function?
1 Like
I kept hoping that DT would make use of idle time to write everything that needed to be written to disk. And to update @Ulli 's simple “file open” flag to a “file has been opened but all changes have been written to disk” flag (aka the buffer has been flushed). Other programs like the RAM-based Panorama X database make use of idle time in this way. And also let the user configure the process somewhat. And it’s great that DT runs verification of the database upon opening but it also could tell the user that no problems were found even though an error dialog is being shown. Perhaps instead of a simple “file open” flag, a system identifier could be incorporated to actually indicate that the file was open somewhere else and show that part of the error message only when needed.
Right now, this error dialog put the burden on the user to recover from a situation that might not be an error condition at all.
