I am fairly sure 2 out of 3-4 times it happened when I renamed a file with to <filename 1)> or <filename 2)>. For example, I had like in the example I took the picture of, and renamed it to <Ball 1)> because I had the intention of creating <Ball 2)> afterward.
It happened before on my Windows (or maybe Linux?) install too. Actually, at that time, I was making changes with Notepad++ as well, and upon checking around before committing/pushing in GitHub Desktop, I saw the problem.
I just went into my smaller, less important vault on Linux and renamed it <filename 1)> but nothing described above happened. Renamed it back and the links updated properly again.
Could be the vault size that is the issue? Or some plugin that is indexing?
I will try again tomorrow to reproduce and will be trying again with number and bracket, with and without plugins.
I went ahead and started tinkering. At first, I couldn’t reproduce it.
Then I chose a file that had a lot of backlinks.
First I found the bugs in my normal vault and after reverting the changes (in GitHub Desktop), I went back and managed to reproduce the same issues without plugins in the default theme (if that matters).
As you can see, I was on the iPad (but I know the desktop installs will do the same).
I made a video (that I trimmed here and there; it is still longish) where I show that some backlinks/Wikilinks are affected.
In the second part of the video, I rename the file back and you can see that now in some files four brackets appear.
In a file I’ve seen a colon and a whitespace “eaten up” as well in the process:
In the file “Fül,” (at 0218 in the video) an “l” character was eaten up along with the space.
Sometimes spaces are added, from what I’ve seen (I’m sorry I didn’t check my repo to see whether the extra spaces were mine from beforehand; I am fairly sure my texts had been cleaned up with myriad regexes, etc.).
Here’s the video I made:
That’s all I can do at my end at the moment, I’m afraid.
How could I reproduce without my intricate web of backlinks? I deactivated plugins and went with the default theme to create the environment needed as a way to rule out any outside influence.
My links cannot have been broken, buddy. In fact, I have recently finished cleaning up every single broken link that may have existed following my port over from MS Word (quite a job, that one).
(Credit is due to Vinzent03, whose plugin was great in helping with eliminating any remaining broken links.)
I do admit that in some cases I have just found double spaces before [[ and I just cleaned them up. Not sure how they were generated and when. It’s even possible none of those were actually from a batch in any way related to my little testing experiment, in any case. It’s usually spaces deleted and brackets added, you see.
But idle talk aside, let’s get down to it again.
So I downloaded this sandbox vault from GitHub and placed 3 whole files (all I have time for) in a folder called ‘Mine.’ The ones I knew from before were playing up.
One of the files (Diana) stayed okay, the other one was playing up. Twice. As you can see, when I did the rename back, it generated the offending bracket again.
As I said, I am not sure if it’s the curly bracket that is causing the problem and why only a few of them will be affected (10 out of 68 links, or so). It’s not the large vault, because I was able to repro in a lean vault, as you have seen.
You know I was looking for a regex to delete those out but I couldn’t find the right code.
Actually, it is kind of maddening to see that red dot when you enter a file.
If I see the dot, I know I have not entered that particular file through Obsidian (I cannot delete it in Taio, for instance, the app I was using before Obsidian mobile got so much better) and I know this file is a “virgin.” Maybe that’s why the dot is red…