I did not discover this bug before it was too late:
This evening was my “note-tending” session. I spent the last couple of hours renaming files and moving them around, happily relying on Obisidian’s magic refactoring to sort everything out. Hundreds of interlinked notes, with very carefully curated aliases for each link (e.g., “Please see [[path/to/note|this really cool study]] for more information”) are now completely exploded with all the links meaningless (“[[path/to/renamed-notethis really cool study]]”).
The vault is under git VCS, so I can roll back everything, but that would lose the dozens and dozens of microedits/tweaks/prunes/grafts etc. I did while tending the garden.
Does anyone have any suggestions on how I can repair my links short of a full revert?
I think one way to do this would be to make a copy of the vault as it is now, i.e. “current-vault”, and then use git to revert everything to where the links are good again. Then you can use some tool to compare “current-vault” to the reverted vault and redo the changes with our without the missing pipe character.
Such diff tools is available for most platforms, and they can be pretty good even when they’re free of cost.
Thanks! That 's a great idea. The problem is that the files and directories have all changed and moved around, so there is a LOT of noise. Made worse by Git sometimes seeing renamed files as new ones instead of rename ones etc.
One thing I’m doing now is trying to use Dataview to find all the broken links and fix them manually. It’s deeply frustrating, and completely blew my evening. But I think it’s recoverable. All’s well that end’s well, etc. And, in any case,I was procrastinating writing a presentation, so now my procrastination/adhd demons have all the busywork they were clamoring for all this time anyway
Files moving around is a little troublesome, folders even worse… still a vault difference comparison could be useful for cleaning up some of this mess.
Alternatively you’d need to use some git tool to go through every change back in time, and change to preserve the “correct” change along with modifications needed.
The only programmatically alternative I see is to loop through all non-existing links, and try to match up the leading part of all file names against that list. That could work, but it would require for all the links to have a full path to the note. Any notes with only partial matches would cause some issues.
I wonder why not use just regex (or a series of them) to revert back (and reinstall an earlier version of your Obsidian)?
Of course, you know far more about the extent of damage than I do.
This happened to me too. By the time I realized I was using a not stringent-enough regex and made a lot of clutter with indentation-purpose dashes, a month or so passed (and now close to 6 months) so, I ruled out a revert and manually delete some dashes here and there.
Still, I might take master holroy’s advice to compare two (now really distant) states of my vault in trying to regain my older, better state without excessive dashes.
I’m not sure if you’ve got a script to show you the broken/unresolved links or not, so I just wanted to present one such script to you.
```dataviewjs
const basedata = Object.entries(dv.app.metadataCache.unresolvedLinks)
.filter(([origin, unresolved]) =>
Object.keys(unresolved).length)
// Build dictionary (or set) with key on the new file
let unresolvedDict = {}
for (let [origin, unresolvedList] of basedata) {
for (let newFile in unresolvedList) {
// If first time we see this, create an array...
if (!unresolvedDict[newFile])
unresolvedDict[newFile] = []
// Push another origin into the array
unresolvedDict[newFile].push(dv.fileLink(origin))
}
}
dv.table(["Unresolved", "Origin(s)"],
Object.entries(unresolvedDict)
.sort((a, b) => (a[0].toLowerCase() < b[0].toLowerCase() ? -1 : 1))
.map(item => [dv.fileLink(item[0]), item[1]])
)
```
If you run this script in some note, you’ll get a list of the unresolved links in the first column, and then the origin of the unresolved/broken link in the last column.
In other words, if you see something in the first column where it’s logically are missing the pipe character to make it into an alias, click on the origin link in the last column and edit the unresolved link. If there are multiple links in the last column for any given unresolved link, that means that you’ve linked from each of those origins.
To refresh the list you’ll sometimes need to either re-open the note with this query in it, or go to the previous file, and then forward again to this file, so that Dataviewjs can get a chance to redo the query. (Another option is to switch to editing mode, add a space somewhere in the query, and then go to reading mode. Yes, it’s a hack, but it does circumvent the no-refresh bug of dataview )
Hope this makes it a little easier to fix all the mangled links, due to the alias bug.
This sounds like it might be something which could be in a post of it own? Maybe we could help you get a proper regex to remedy some of the situation with excessive dashes?
Turns out I have quite a bit more broken links than I thought, beyond more than the bug induced mess, so I guess this gives me the opportunity to fix things.
I pasted the list of broken links into a python script with a dictionary mapping to the correct links where it could be figured out easily, and then ran a vault-wide regular expression search/replace.
That really cleaned up things
Still a lot of things to be fixed, but now it’s all just the typical background busywork.
I am reluctant to explain the obvious: I do not have “ver. 1.2.1.” You need to pay to be a tester? Isn’t that counter-productive?
On the other matter, well, I looked into my commit history and while I made sure my commit messages reflected the regex jobs done (with regex101 links), I couldn’t find it and did not go through with it.
But I appreciate your reach-out and good to have you onboard.
And, in any case,I was procrastinating writing a presentation, so now my procrastination/adhd demons have all the busywork they were clamoring for all this time anyway