Rename, move and trash
Renaming, moving and deleting a file inside the app keep its assets consistent; renaming or moving a note inside the app also updates the links to it.
How to reach it
- Rename — the row's context menu, File → Rename…, or the pencil next to the title in the editor header.
- Move to Trash — the row's context menu or the top bar's trash icon, for any file. File → Move to Trash works for a standalone file only. Delete folder in a folder's ⋯ menu does the same for a whole folder.
Rename
The file extension is fixed; you only edit the name. If the file has an
<name>.assets/ folder (images you inserted), renaming carries it along and rewrites every image
link in the document in the same operation. A name that collides with an existing file reports an
error and changes nothing.
Rename outside the app
Inside a tracked folder, a rename in Finder keeps the note's history and
open tabs only when the next scan proves the match: same directory, same extension, exact nonzero
modification time, and a unique match in both directions, plus a content proof. Raven first compares
its last accepted text. If that copy is absent, the desktop compares the new file's raw Git blob
with the old path's blob in the Git index. A mismatch never falls through to another proof.
Only a row that was not missing before this scan can follow; excluded or gitignore-hidden files
cannot become the rename target. Without proof, or when any check fails, the original row stays
missing and the visible renamed file becomes a new row. A never-opened non-Git note takes this
fallback because it has no accepted copy; other notes can also lack a copy. A Git file with changes
that differ from its index takes the fallback too. Hidden or excluded files remain unadded.
So does a Git file renamed with git mv (or already staged), and a Git file whose line endings
Git converts on checkout, which is the default on Windows.
Renaming outside the app does not rewrite links to the note or image references. Its existing
assets folder stays at the old path when renaming it would break those references.
Move
Dragging a file onto another tracked folder row moves it on disk, along with its assets folder. Moving a folder moves everything inside it. Moving a file in Finder is picked up on the next scan: if nothing already exists at the destination and the file's content still resolves correctly, its assets folder comes along too.
Links to your notes
After you rename or move a note or a folder inside the app, the links to the notes it touched are
updated, with no prompt and no success message: [[wikilinks]] and Markdown links to a .md file,
in your other notes and in the moved note itself. A wikilink that still points at the same note
after a move keeps its spelling. Each note that changes gets a Before link update entry in its
version history — see Versions and Git history.
The note you have open is updated like any other, and the editor switches to the new text without moving your place in it. If it has unsaved changes, it is left exactly as you have it, and its links are counted in the message below instead.
A link that cannot be updated safely is left as it was, and one message says how many links need a
look and in which note: the note changed on disk in the meantime, it has unsaved changes, it holds
text the app could not read exactly (rewriting it would damage it), or the
link is in a form the app does not rewrite (a reference-style link, a path with a backslash escape,
or a file name spelled with an HTML entity such as &) and no longer reaches its note. A link to a DIFFERENT note that a
rename makes resolve somewhere else is never rewritten either; the message counts it separately.
Links to anything that is not a note (an image outside the note's .assets/ folder, a PDF, an
.html file, an HTML <img> or <a> tag) are neither updated nor reported. Check those yourself
after a move; updating them automatically is planned.
Renames and moves run one at a time. One you start while another is still updating links waits for it to finish.
Trash
Move to Trash always sends the file to the
Trash — never a permanent delete. It works for both standalone files
and files inside a tracked folder, including .yaml and .json files. Trashing a note also
trashes its assets folder. You can restore a trashed file from the
Trash the same way as any other file you put there; the app has no
record of it once it's gone.
Trashing or removing the open file
Moving the open file to the Trash, or removing it from Recents, opens the next most recently changed Markdown file — the same one at the top of the sidebar's "Last changed" list — instead of leaving you on the empty editor. Only when there is no other Markdown file to open does it land there.
Missing files
If a file has gone missing, its rename, trash, and Reveal in Finder actions are disabled — only the recovery banner's own actions apply. See When a file goes missing.
Other row actions
- Copy File Path copies the absolute path, even for a file that is currently missing.
- Reveal in Finder opens the file's location.
Limits
- There is no permanent delete anywhere in the app; everything routed through Move to Trash goes to the Trash.
.yamland.jsonfiles cannot be renamed from inside the app — see YAML and JSON files.- Link updates only reach a tracked folder's own visible files — a note inside that folder's Excluded Paths setting is not scanned, by the same design that excludes it from search.
- A link to anything that is not a note, and a link written as an HTML tag, is neither updated nor reported after a rename or move.
- A rename or move waits for the one before it. If writing a note hangs (a slow or disconnected drive), renames and moves started after it wait until that write returns.
- Quitting the app in the middle of a rename or move can leave its link updates incomplete — the rename or move itself always finishes cleanly first, but a link fix interrupted mid-way is not resumed on the next launch.