Renaming notes messes up text area around updated wikilinks in files with BOM (byte order mark)

What I tried

Search forum for renaming issues.

Steps to reproduce

It happened 3-4 times already.

Expected result

When renaming files the updated links elsewhere respect right number of whitespace characters and double square brackets.

Actual result

Whitespace character before [[ is missing and an extra ] is generated.


Windows 10 and iPadOS 15.6.

Additional information

As you can see, I need to look for and handle with find’n’replace these cases (I did it with Notepad++ on PC, if anyone is interested).

I am actually not sure if these bugs happen only when a number and a normal bracket ) are in the filename.
The issues happened on desktop before and now on tablet.

How can I reproduce this? what are the steps?

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.


Can you post a screen recording of this happening in the sand box vault?

It looks like your links were broken at the beginning of the video.

I am not sure I follow you.

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.

The screencast is here:

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.

The sandbox vault is the one you get by pressing F1 or the ? the le lower right corner.

Can attach a copy of the 2 files where this happens, before it happens, so I can try to reproduce myself? Because I have been unable to do it.

Ah, okay. The tester me hasn’t seen this feature before. Seems like it’s pretty much the same structure as the one on GH.

I’ll attach the three files I was using last time around.

Dió.md (19.1 KB) (3.5 KB) (326 Bytes)

Try renaming to a filename that includes a normal bracket, like I did. This must be key. Or possibly it is the formatting of the actual lines in which they get broken.

I mean if it was any old way of renaming issues, you’d have heaps of reports, right?

There is a problem but it has nothing to do with backets or parenthesis in the title. In fact, the bug happens when you rename with anything.

The problem is the BOM character, that red dot at the beginning, in one of the affected file.

Renamed bug report. We don’t support UTF8 with BOM, but we should handle better this case.

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…

Thanks for looking into it.

Found it.

Regex match: ^[\ufeff]
Replace with nothing

The red dots are gone.

Cheers, mate.


For anyone interested.

Note that this regex will only work in individual MD files. Unfortunately, there is no way to use regex to batch delete the red dots using NotePad++.

For that, this Python script must be used (in Notepad++ through plugins):

import os;
import sys;
filePathSrc=“<PATH, e.g. C:\\USER\\USERNAME\\Obsidian\\Vaultname>”
for root, dirs, files in os.walk(filePathSrc):
for fn in files:
if fn[-3:] == ‘.md’: + “\” + fn)
console.write(root + “\” + fn + “\r\n”)
notepad.runMenuCommand(“Encoding”, “Convert to UTF-8”)

After running the script on my entire vault, I can confirm no anomalies occur with renames.

Starting with 1.1.13 the BOM will be removed every time obsidian opens a file.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.