Text Editor Links: Repair Relative Paths After Moving Files

An abstract editorial scene showing how to enumerate sources and targets before moving files, then verify every rewritten relative link

When links break after a file move, compare the path written in the document with the target’s new location. Do not assume that the editor followed the move automatically. Repair one reference, open it, and use that proven route for the remaining links.

This guide is about recovery after reorganizing a project. It is not a guide to creating new hyperlinks or opening web URLs from selected text.

Think from the document’s new location

A relative path is a route from the document to another file. Moving draft/chapter.md to manuscript/chapters/chapter.md changes that route even when the image stays put. Sketch the document, the target, and their shared parent folder before editing.

Avoid replacing the path with a location that works only on your Mac. An absolute path can hide the problem until the project is copied or shared.

Repair three references without widening the damage

Suppose the chapter links to a cover image, a character sheet, and a research note.

  1. Duplicate the moved chapter.
  2. Record the three old link strings.
  3. Confirm that each target file exists.
  4. calculate and replace only the first relative path.
  5. Open the target and verify its contents.
  6. Apply the same reasoning to the other two links.

Rune Studio’s product documentation describes support for links in text files and path updates after moves or renames. The test completed for this guide, however, used an explicit text replacement after moving a file. That proves a manual repair path, not automatic path following. This article keeps those two claims separate.

Set a boundary before bulk replacement

Count matches before replacing anything across files. Limit the folder and file types, and stop if the old string also belongs to an unrelated asset. After saving, search for the old path again, then open every new target; zero old matches does not prove that the new destinations are correct.

If the number of candidates is unexpectedly large, return to the untouched copy and narrow the scope. If a link reaches a same-named but wrong file, compare the target contents rather than trusting the filename.

Conclusion

Reliable relative-link repair depends on three fixed facts: the document’s new location, the target’s location, and the expected number of changes. Rune Studio’s automatic-follow behavior was not demonstrated by the recorded replacement test, so verify it separately before relying on it. Review Rune Studio’s workspace features