Add another file within the folder, and add a link to “Untitled” in a property.
Create a file inside root (outside of the folder) using the new note command (cmd + N), a file called “Untitled” will be created.
Go to the file created at step 3, the link has changed to the root file “Untitled”, even though it was previously referring to the “Untitled” inside the folder.
Did you follow the troubleshooting guide? [Y/N]
Y
Expected result
I expect to see the popup that asks me to update internal links
Actual result
My link refers to the wrong file and i cant update it because i didnt get to see the popup.
Environment
SYSTEM INFO:
Obsidian version: v1.10.6
Installer version: v1.9.12
Operating system: Darwin Kernel Version 25.0.0: Mon Aug 25 21:17:36 PDT 2025; root:xnu-12377.1.9~3/RELEASE_ARM64_T8122 25.0.0
Login status: not logged in
Language: en
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: off
Plugins installed: 2
Plugins enabled: 2
1: Excalidraw v2.17.2
2: Abstract Folder v1.4.1
RECOMMENDATIONS:
Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.
Additional information
No. its easy to replicate. Although i do wanna say, this type of link management is problematic. Even if i create a file thats not called “Untitled” and something else, I dont think asking the user "Do you want to update internal links that link to this file? makes sense at all. What file are you talking about? I get this pop up when i create a file that has the same name as another file that already existed, so there is no links to it. But im being asked whether i want to update internal links that link to this file? even though its reffering to the file that was already created before?
Thanks for your time : )
It looks like the issue here is that if you create a new note (or rename an old one) such that the new or renamed file will be targeted by existing links, you will then be in a very bad place, whereby any further renaming will corrupt your existing links, unless you rename the file outside of Obsidian.
There are some end-user workarounds possible here, but they’re not very good as they require changing everyone’s workflow and/or avoiding Obsidian defaults all the time in order to avoid an infrequent mishap.
So on the Obsidian side, a relatively simple fix might be to have the FileManager.createNewFile() logic check whether a generated name has an existing link resolution (i.e. links exist that would resolve to the new file, if it existed), and modify the intended filename until it’s unique. That would avoid at least this specific scenario (Untitled in in different folders), though there would still exist ways to trigger the overall issue of highjacking existing link resolutions.
(Also, when a user renames a note, if they are renaming to a name that will alter existing link resolutions, they should probably get a warning dialog for the same reason.)
i do wanna say though, do you think it would be better to just have to full path when referencing another file? if its not visually appealing i think it can just be trimmed or not shown.
The problem is actually not that bad. Because obsidian does try to handle it in other scenarios where files are named the same and links have to be updated. Its just that in this specific scenario the logic for showing the popup isnt shown when the new file command is used to create a file. if you do try it with a file thats not “Untitled” it would show the popup.
but then again i go back to my point, the popup doesnt make that much sense, its hard to tell what its referring to.
When you do click “Accept Once” it just updates the path in the property to a full path. Cant that be done from the beginning? instead of having to update it only when theres same named files?
yes, it can be done in the beginning. That’s what “Path from vault folder” is for. If you are okay with it, use it. We should still handle the problem you raised on note creation when using the default “shortest path”. It seems to be pretty specific to note creation (hence collision of “Untitled”), note rename is already handled.
@WhiteNoise No, only the new notes creation - you’re right that that case is already covered (by it updating the existing link). Sorry for the red herring.