Per this thread, Dropbox has released a new version that goes with the new Mac OS 13.0 “Ventura.” I want to offer a warning for people who index PDFs – don’t install the new Mac OS or new Dropbox until you can set aside some time to rewire the index pointers for your DevonThink database!
The new MacOS requires Dropbox to move to a “CloudStorage” folder inside I think the “Libraries” folder. If you index files to Devonthink from a Dropbox folder, this will break all your links. Worst case, you open DevonThink and it looks for the indexed folders and doesn’t find anything and then just starts deleting everything [!!] including propagating those deletions back to the DevonThink Dropbox sync store [!!!].
But fear not. Per @cgrunenberg, there is a fairly easy solution. Here’s what I think is the best order of operations for Mac OS and Dropbox updates for anyone who indexes files on DevonThink.
Open DevonThink. Go to Preferences/Sync, and choose your Dropbox sync store. Then select the “Manually” option so that DevonThink will wait to change your files until you say so. Close databases and quit DevonThink
You can’t type in a new path, but if you hit the dropbown at “Path”, you can navigate to the new location.
Manually sync your database and update files from the File dropdown. And I think from there things should work smoothly. At least that’s what I’m trusting is happening now…
[this whole post is rewritten to begin with the solution rather than create a step-by-step walkthrough on the problem]
You could also update the path of the enclosing folder(s) via the Path pop-up of the Info inspector. Another possibility is to create a symlink ~/Dropbox pointing to the new destination of the Dropbox folder (e.g. OneDrive and Google Drive do this).
You know, I do have a question. Three of my databases were saved by implementing @cgrunenberg’s timely suggestion. But I didn’t get to two of them got fast enough: they automatically indexed to the empty location, deleted all their files, and automatically sync’d those deletions to the sync store.
The fix seemed simple (if tedious) - simply syncing the exact same files from their new location to the exact same database. The problem? Links. When I indexed the folder to the same database again, even though it has the same file structure, names, etc etc etc, none of the links I’ve made to any of those PDFs from other databases work. To DevonThink the newly re-indexed files are simply new files, with new Item ID#s.
So I tried to trick it. I deleted the current instance of that database from my hard drive. I replaced it with a backup of the same database from a couple days ago. I opened DevonThink, paused all sync’ing and indexing, and fixed the indexing link in the backup version so that it properly pointed to the new Dropbox location–where all of the PDFs it’s looking for should be. And behold, they were there, and all was good. Or was it…
Here’s the problem: almost all my links from other databases into this one still seem to be broken. The weird thing is that it’s not literally all; maybe 5% still work, even though I would have assumed this should be an all-or-nothing deal since the problem is at the global level?
Does anyone have any suggestions for why links wouldn’t be working again with my “restore from backup” solution? I wouldn’t ask about such a minute quesiton, except that in my case it’s a pretty significant one: cross-links from my “notes” files into original source documents has become my constant citation tracking mechanism, and if they’re all broken…yikes.
Before I open my main note-taking database to check its links, I’m going to ask a dumb question b/c I am trying to be cautious. Should I now DISABLE the hidden preference “DisableFilesystemEvents”
as described here:
The On link enables this hidden preference but the preference on its own disables actually filesystem events as they’re enabled by default. Therefore yes, please use the On link.
I actually followed all your instructions here already. That includes #2 “Enable the hidden preference.”, which I did by copying the link from “ON” and pasting it in a browser, then restarting DevonThink and re-installing the backup.
I’m now asking how to get things back to ‘normal’ / baseline, after having restored the database. Am I right that I should do that by copying the link from “OFF” next to “DisableFileSystemEvents” above, and pasting it into a browser etc?
Just reporting back that I did the following:
(1) restored the backup of my PDF database in the way you described,
(2) ran “Update Items” on the relevant folder,
(3) synchronized the backup,
and (4) opened my note-taking DevonThink database and tested whether its links to the PDF database worked any better.
Unfortunately, it doesn’t seem to have made a difference–95% of the relevant links in the note-taking DevonThink database are still broken and just say “boink” when you click on them. But that ~5% (or whatever) still works. Really weird.
At this point I’m inclined to give up and just hope to figure it all out as necessary down the line when I go to writing mode. If you think there’s any mileage in opening a support ticket and sending you guys the two databases, I’m certainly open to it. (FWIW, the note-taking DT database isn’t so big, but the PDF one is like 5gb with like 2000 files, so I’m not even sure if that’s possible.)
But if your best judgment is that this is probably just broken because of the combination of Dropbox move + DevonThink “re”-undexing, I don’t want to take up any more of your guys time. Really appreciate the effort to help!
Yep, I did the path update first. It was me who should’ve been clearer! Please insert: “(1.5) updated the paths in the Inspector to the new Dropbox location” : )
First, apologies for the long response here. Just want to be sure I’m communicating the issue correctly! It’s not that anything failed mid-process during the restore–at least not in any way that was visible to me. The failure, if I’m using the right word, happened earlier.
Here’s an oversimplified version of the big picture problem:
There are two key DevonThink databases. Database A = indexed PDFs. Database B = all my text notes on the PDFs in Database A. Database B’s notes are pervasively linked to the relevant files and pages of PDFs in Database A.
Dropbox relocates. Before I realize the implications of this for Database A’s index structure, I stupidly open up Database A, which automatically re-indexes–and deletes everything in itself, because it now sees nothing in the path where it’s looking. Even more stupidly, I don’t stop it from syncing after it’s done this (partly because I didn’t really understand what was happening, while it was happening.) So Database A is now empty both locally and in the sync store. The actual underlying PDFs are all perfectly fine; just in the new Dropbox location.
After various fixes fail, it becomes clear that the best solution is to re-create a folder in Database A (the old indexed one vanished) and index it to the PDFs in their new location. Takes a while, but, yay! It works. All my PDFs are back in Database A, and everything looks the same . . . but none of the links into Database A from Database B are working, presumably because even though DT was “just” re-indexing the same files that previously existed, from DT’s perspective it was creating a whole new array of Items.
That’s the point at which I tried this: shutting off automatic index/sync, enabling the “DisableFileSystemEvents” thing, restoring a backup of Database A, fixing the Inspector pathway for the main indexed folder, then “updating Indexed files” and “syncing”.
Theoretically that should have fixed the links, it seems like? Database A should have the same indexed structure because its root Index folder is the same one that existed before the relocation forced its deletion. (Right?) And nothing whatsoever has changed about the folder structure inside Dropbox. But only about 5% of the links to Database A from Database B work–and previously all of them did. (The fact that some work and some don’t is arguably the weirdest thing of all.)
I know that’s really really long recap, but I want to emphasize that I don’t see a problem appearing at any point during the new restore-backup-of-Database-A-and-then-index-it process; it’s just that doing this hasn’t fixed the larger problem of almost all the links in Database B being dead.
I wouldn’t blame you for throwing your hands up and saying ‘no clue’ at this point. . . .
That is indeed very strange as setting the path to the new Dropbox location should just resolve the file paths in the database’s index. It doesn’t import or modify anything.
Hi,
A naive question @MichiganUser; Is the new location “CloudStorage” the default in Ventura? I installed Ventura (13.0) last night and everything looks piccobello in Finder. I don’t see a moved folder for Dropbox. It’s still at $Home/Dropbox. Even iCloud seems to be in the same place.
I haven’t started DevonThinkPro however.
The location is dependent on the version of Dropbox you use; my guess is that if you updated to macOS 13.x from macOS x.x then you may still be using an unaffected version of Dropbox. @rmschne reported that versions from at least v159.4.5870 were implementing the change in question. If you perform a fresh install of macOS 13.x and all your software then I guess you’d be affected immediately, as any version of Dropbox you download now is presumably going to display the new behaviour.
Yeah, my Dropbox update was a prompted update that I accepted from Dropbox. (It promised “new better affirmative integration with the newest Mac OS!”–sigh.) It did give a warning that stuff would move around during installation, but the DRopbox updates usually say something like that, and I must just not have read it closely.
But bottom line, Ventura alone doesn’t do this. It’s the Ventura-oriented update of Dropbox that does–or at least that’s how it seemed to go with me.
