backup Files.noindex via hazel from DTPO

you are right, the “date added” changed possibly after a rebuild-command that i did in order to unmess verifcation errors.

(By the way, why “should” DB correctly do so? If a user adds a document le 12.3.2012, there is no reason that this becomes 9 of July 2015, whatever command he performed!?)

The fact is that this now makes very difficult to synchronise one Timemachine database version with the newest.

Support wrote me what to do, but i didn’t have the time to perform this, for the moment, i work with the newest database and every time when i think missing a file, i open several TM-Versions oft the DB.

It is useful to understand what particular data elements signify rather than make our own assumptions about them. Especially if one is going to do unusual and complex operations involving comparison with other data sources such as Time Machine.

The addition date is defined as “Date when the record was added to the database.” When a database is rebuilt, the data are exported, a new database created, and then data imported into the new database. Thus, the date added is the date of the rebuild. That is correct, in terms of the definition of that data element. It’s also why I pointed out that addition date is a database “bookkeeping” element.

OK. But where can i see when the Doc has been added to the database, after a rebuild command? What is the name of the DB-Field? Created is wrong, as you might have scanned a PDF in 2005. You add it in 2014 to your DB, and afterwards, if you have to sync a Timemmachine copy of 2013 with the actual DB of 2015 after Rebuild? Something must be able to show you that this document from 2005 has been added in 2014…

How can i sort the data in a group in order to find one by one the docs added in 2014?

And also:

I dont’t want at all make unusual and complex operations. I only want to know which data has been killed, in order to retrieve it in Timemachine-Copies, this should be not too complex for the user. In a Dropbox-Account for example, it is very easy to retrieve deleted items, or even to have a look on different version.

Perhaps it could be a good idea to keep the records of every element that came in the DB, forever. Assuming preview and classify data takes something line 20-30 KB per element, this won’t make your database too big. And if so: you can start a new one.

I’ll try this again. The date a document is added to a rebuilt database is the date the database was rebuilt. DEVONthink doesn’t keep an historical record of previous adds to previous databases or to previous incarnations of the now-rebuilt database.

I’ll exit, now, and wish the OP well sorting their piles. This thread is going in circles.

It is not goin in circles, it becomes clear that once again, everything is users fault while working with a perfect software.

Please,why there is nowarning that by rebuilding the database, i will use every useful “date added” record? The chronological order of the incoming documents can be very important (as it is the case for me). It is unbelievable that DTPO decides to kill this information, without a clear warning.

Note that the ranges of Date Created and Date Modified can also be useful for comparison of states of a database over time. As most of my databases incorporate notes that I’ve created in the database and frequent Web captures, Date Created sorts are pretty good distinguishers of differences over time.

If you wish do to absolute comparisons of database contents over time, it’s possible to create plain text lists of all documents within a database. To do that, Either in the History view or in a smart group that lists all documents, select all and copy to the clipboard. Past the clipboard contents into a new plain text document. For example, I could create a list of the more than 30,000 documents in my Main research database, and compare the list to a similar list of an earlier state from a Time Machine backup. There are third-party applications that allow one to compare two such documents and identify their differences, which you could find by a Google search. (Your initial proposal of making backups of Files.noindex would likewise benefit from such a comparison of filename lists, and would simply add another complication to keeping backups, so isn’t recommended.)

You mentioned that you have 16 “versions” of your database, including Time Machine backups. I’ve got many more than that, as I’ve got years of Time Machine backups, as well as a number of Database Archive backups. That’s a Good Thing, not a Bad Thing.

My most used databases are modified very frequently, adding new content and sometimes removing or archiving from the database obsolete content. Sometimes I rename documents, especially scanned documents, after capture to a database.

Caution: If you start restoring backups to compare their contents with your current database, don’t get confused about what the current database is! Before restoring older states of the database, I always zip the current database file (important – close the database first). After restoring earlier backups (which will of course replace the current database), I can always return to my current database simply by deleting any older version and unzipping the current database.

I’ve never had a problem with files going missing from my own databases. I’ve been using DEVONthink heavily for 13 years now. I attribute my database reliability to maintaining good habits including periodic checks using Verify & Repair to make sure the databases are sound and also that sound backups are being kept, and to keeping the computer and its operating system sound by preventive maintenance routines. I haven’t had an error report by Verify & Repair in a long time, probably a couple of years. I haven’t had to resort to a database backup because of damage, for more than 5 years. My current late 2012 MacBook Pro Retina has been a delight. But if I had not followed preventive maintenance, especially periodic checks of the Disk Utility Verify Disk procedure, I would probably have had serious data integrity problems not only for my DEVONthink data but everything else. I’ve had to correct SSD disk errors 7 times. Had I never checked, I suspect I would have experienced a crashed disk – and before that happened, my computer might will have lost or overwritten files on the computer.

Thank you very much, Bill.

Thank you, i will try this , very good idea!

Here, at least one “verify and repair” needed every two weeks…
Perhaps Verify and Repair Disk under MAcOS could rally help, but this never gives errors here.

I think the errors comme from syncing.

And as i said, i don’t understand why:

  • when sync conflicts occur, DTPO should say what he will do exactly

Same thing when Verify and Repair reveals “incoherent items”.

What does DTPO do when it repairs 78 inhorent items that i had five minutes before posting this? Why DTPO does not log the changements in the Log, or in MacOSx COnsole?

Many many times i said “OK, repair”, but i had no idea what DTPO did with my data…