Batch Update Local RTF Links

I have many DTPO links in RTF files that point to files in a “Data” directory on a drive; eg…

file://localhost/Data/Accessories,%20Games%20DATA/
file:///Data/Innovation%20&%20Prototyping%20DATA/
file:///Data/Publishing,%20Printing%20DATA/
file:///Data/Multimedia%20DATA/

```I duplicated all those target files to another mounted drive and now want to batch update all the DTPO links to point to their new location.  Is there a script or other easy way to accomplish this?  

And/or how do I get localhost to point to the new location and why are some links localhost to begin with?

An example of manually created link for a file in its new location in a "Data" directory on the new "Mini #1 HDD" drive…

file:///Volumes/Mini%20%231%20HDD/Data/Multimedia%20DATA/HTPC%20Lessons%20Learned.pdf

file:///Data/Multimedia%20DATA/

file:///Applications/Android%20File%20Transfer.app
file:///Applications/Kindle.app

  1. RTF files are a poor format for making changes like this. Can it be done? Sure, but it would not be trivial.
  2. How did you generate the links in the first place?
  3. You’d need to ensure uniformity, providing an example of the original location and the new location. You are presenting enough variability in your question that just manually making new files may be more efficient.

Thanks for the response Jim.

The links were created by CMD+OPT and dragging the file in from a Finder window. Then the displayed text in the RTF file might also be slightly changed; eg, removing “.pdf” or “.epub” from the displayed text.

The original (current) file location…

file:///Data/
(on the startup HDD)
```The desired (new) file location…

file:///Volumes/Mini%20%231%20HDD/Data/
(“Mini #1 HDD” without the escaped characters)


The "localhost" links remain a mystery (to me).

I might be wrong but it could be that this is a remnant of DT vers. 1 (I faintly remember that they completely overhauled the file structure).

This would be my quick approach… and I strongly suggest you test it out on a few copies of some documents, as it replaces the file in-place. There is no undo with this. Actually, I would suggest making sure your local backups are up to date, as a general and specific thing.

This will work on selected RTF files. It is meant for the specific conditions reported here. So, to anyone else reading this, the script is specifically coded for this case. Could it be modified for individual cases? Yes, if one was so inclined, but it would require forethought and testing.
DT Replace RTF Links.scpt.zip (2.46 KB)

I get the concept of using sed for in-place replacing then over-writing in the raw text. The script works for me just as you intended on selected files.

But aargh, details can get you! Specifically I’ve found a large number of my records with links to be changed are actually RFTD and not RTF.

Then going through and selecting records leads to prune and update questions. And that leads to reviewing source documents. And that suggests that it might be more efficient to work from those sources first. Then back to revising the DTPO links.

So Jim, your original suggestion to perform this updating manually was the best advice. Especially when also dealing with a large amount of RTFD record exceptions. And the reality is it is probably better to review the value of those many long-forgotten sources and links.

What about if I moved the entire database from the startup disk to another drive? Are all links unaffected if they are inter-database links (x-devonthink-item://…)? Any other significant effects from a move?

And exactly what is best way to move a database?

Thanks for your help and insights with this.

:smiley: I’ve been doing this kind of thing for a loooooong time (including in corporate environments with a long history of legacy documents and a general lack of uniformity :mrgreen: ).

The x-devonthink-item links (what we call the Reference URL), is immutable, so moving a database has no effect on them.

Close the database in DEVONthink, then move the .dtBase2 file.

Wow, super quick, useful, concise reply. Definitely no “loooooong time” there.

Thanks Jim.

You’re welcome. Cheers! :smiley: