Unexpected Modified Today

DEVONthink
#1

I’ve just done the following:

  • imported a PDF (PDF 1) via the inbox
  • move the PDF to a group automatically via a smart rule
    • the same rule tags, and locks the PDF (lock symbol)
    • note: the PDF is of a type which cannot be edited by DT (i.e. it is locked by DT to avoid damage to the PDF when editing; i.e. the crossed out pencil symbol is present)
  • scanned a document (PDF 2) to the inbox (as PDF from ScanSnap, OCR on import)
  • via the Today smart group:
    • opened PDF 1 in Preview
    • dragged and dropped PDF 2 into PDF 1 in Preview
    • closed Preview, thus saving PDF 1 back to DT

At this moment, two additional items (PDF+Text) appeared in the Today smart group; these items were both created in 2019 and are stored in the same database as PDF 1. The Modified date of both items has suddenly changed to today, now. Examining them, it is not clear that they have, in fact, been modified in any way.

I have observed this behaviour once previously, but cannot currently report whether I can reliably trigger it in the way described.

#2

Are these really additional items in the database or just new results of this smart group?

#3

No, they are just new results of the smart group - i.e. their modification date changed at the exact moment I saved PDF 1 back to DT from Preview.

#4

What OS are you running?

#5

What’s the modification date of the files in the filesystem? Also today?

#6

macOS 12.4

Good question - no; the modification date in the file system is unchanged (August and September 2019). What is interesting is that for those files the Created date also isn’t synchronous. You may recall that I alter the creation date in DT to equal the “paper date” of a document. Whilst for several random items I have just checked that creation date is identical in DT and the file system, at least for those 2 files in question the creation date in DT and the file system are divergent.

#7

Thanks for the info! Does this still happen after disabling all smart rules (see contextual menu of sidebar)?

#8

I don’t think I can answer that; I can’t easily simulate the situation in my test database. I don’t even know for sure that I can reliably trigger the condition. I’ll look into setting up a dedicated test database, but that would be quite a significant effort; just deactivating all smart rules would take some time. As an intermediate step, I intend to try and mark items whose internal and external creation and/or modification dates don’t match. I’ll report back as and when.

#9

Just select all of them in the sidebar and disable the actions via the contextual menu.

#10

Again what learned, as they say :wink: Thanks!

I’ll look into trying to recreate what happened, and will report back. It won’t happen any time the next number of days, as I need to recreate the documents in their original condition and set up a test database for the purpose.

1 Like
#11

This doesn’t happen often enough for me to have a chance of determining whether or not deactivating smart rules is likely to help.

I’ve stumbled on another occurrence today - an item whose creation date in DT is 02.02.2022 but 06.02.02022 in the file system (which is the date it was added to DT), and which took on a new modified date today, again not reflected in the file system. The SHA1 hash remains unchanged however, such that there is no evidence that the file has truly been modified in any way.

Altering the created date in DT sees that change reflected to the file system, suggesting that for whatever reason when I added the item to DT, changes made to its metadata were not being reflected at the file system level.

I’ve made a note regarding some particulars (where the item is, that it has a stamp attached and so on), so if it happens again, perhaps a pattern will emerge. And I suppose I could script something which compares the metadata on items in DT with the metadata at file system level to see if I can pick up any more instances.