DEVONthink 4.4.1, macOS 15.7.5, OneDrive 26.168.0830 (File Provider, ~/Library/CloudStorage/OneDrive-Personal). The folders are indexed and not synced via DEVONthink.
That behaviour is valuable to me. As long as the record exists I can restore the file from OneDrive’s Recycle Bin, point the old record at it (Generic Info > Path > Select) and keep its UUID, so x-devonthink-item:// links elsewhere keep working.
This week it didn’t work out that way:
OneDrive deleted an indexed file. The Log reported it as missing.
I Control-clicked the Log entry and chose Reveal. The record disappeared right away, UUID included. Nothing was in the database’s Trash.
I restored the file from OneDrive’s Recycle Bin. DEVONthink indexed it as a new record with a new UUID.
In two earlier cases, records reported as missing in the same kind of folder stayed put for over a day, and I selected and opened them many times. I don’t think I used Reveal in those cases. Another user described something similar, with items disappearing on click but one staying missing (Some files become "missing files", some are quietly removed).
Questions:
Apart from Update Indexed Items, which actions remove a record whose indexed file is missing in a cloud folder: Reveal from the Log, selecting the item, selecting or viewing its parent group, Verify & Repair, anything else?
If the file reappears at exactly the original path while the missing record still exists, does DEVONthink reattach it to the existing record (same UUID), or create a new one?
Is there a safe way to keep a missing record until the file is restored, so its UUID survives?
With the hidden preference EnableFSEventLogging on, where do the log lines go: Window > Log, Console, or a file?
Some test results, in case they help others (DEVONthink 4.4.1, scratch database, dummy files in an indexed folder inside OneDrive, deleted with rm):
Missing documents (plain text) kept their records through selecting, opening, opening the group, Verify & Repair (Cancel) and Reveal from the Log. Only Update Indexed Items removed them. That matches the cloud-folder behaviour described in earlier threads.
Missing bookmarks (indexed .webloc, “Web internet location”) lost their records, UUID included, as soon as they were selected. That includes the automatic selection of a single search result and Reveal from the Log. Reveal took me to the root with nothing selected, so the record was gone before it could be selected. Merely listing them in an expanded group, or running Verify & Repair, didn’t remove them.
A file restored to its exact original path reconnected to the existing record (same UUID), both for a document and for a bookmark.
So the record I lost this week was a .webloc, and my Reveal is what removed it. Is the different handling of missing bookmarks intended? For links, keeping the record until the file comes back, as with documents, would be much safer.
Development would have to comment on the bookmarks immediately disappearing. However, they are basically content-less files. They functionally only point somewhere else unlike say a rich text document.
If the file reappears at exactly the original path while the missing record still exists, does DEVONthink reattach it to the existing record (same UUID)
Yes and it’s based on the absolute path so it doesn’t actually need to be the same document. It just needs the same name.
Here I added a bookmark to a completely different site but gave it the name of a different site. When viewed in DEVONthink, it retained the UUID.
Clicking on a missing indexed file of any kind doesn’t make it disappear from the group in DEVONthink. It is shown with the registered file path and a note it’s missing.
