I’ve opened an issue for this: Symbolic links and hard links can result in the same physical file being open in multiple tabs.

It seems the matter is not as straightforward as it appeared to me. At least one person strongly disapproves of changing the current behavior at all.

I don’t really use symlinks. If some of you do, and have clear ideas about how they should work — whether they should resolve to the target name, like a shortcut, or remain as their own name in their own directory, like a hard link — you might be able to contribute to the discussion at the link above.

Three notes:

1. I offered a pull request along with the issue, but another user (the same one who objects to changing anything) discovered an important flaw. While that’s mixed up in the discussion, it’s really a separate issue from what should happen. If we reach a consensus on what should happen, I’m sure there will be a way to fix the flaw (which causes symlinks with a relative path to fail completely).

2. As things are, File|Open and double-click in Explorer behave differently than opening from the command line and right-click|Open with Notepad++ in Explorer. I see no way to change the File|Open and double-click behavior, because Windows is resolving the symlink in those cases before Notepad++ ever sees it. As far as I can tell, the person who doesn’t want things changed believes the other behavior is “correct,” and doesn’t care that the behavior in some cases doesn’t match. Honestly, the more I look at the way different programs behave, the more it seems to me there is no consistency regarding this in Windows. I’m not sure if that’s an argument for letting the chips fall where they may, or if Notepad++ should still at least be consistent with itself.

3. Though I now think I was unwise to do so, I combined two distinct issues: opening symlinks in particular, and avoiding opening the same file by two separate names (which affects both symlinks and hardlinks). The latter is the one more directly relevant to the original complaint in this thread. The fix for that appears straightforward and is independent of the flaw that caused a problem with my pull request. (My solution just activates the tab holding a file which is already open, regardless of whether you’re trying to open it under a different name.) However, the user who does not want anything changed apparently does not want Notepad++ to suppress opening the same file under two different names either.

maybe this is symbolic links issue then, I use those

At first I couldn’t reproduce this issue with Notepad++ 8.5.6, 64-bit, on Windows 10, then I noticed something.

If you open a symbolic link using File | Open… or by double-clicking in File Explorer, the target name appears in the tab. When opening by command line, from the File Explorer context menu, or from the previous file history (which can happen when the symlink name is already there due to having previously opened it used one of the other two methods), the symlink name is displayed.

My guess — I haven’t looked into the code — is that when Windows knows it is opening a file, it is automatically returning the target path for symlinks (as it should); but for command line and context menu, Notepad++ is just working out the fully-qualified path name of the link without checking for the file name after the file is open and Windows has resolved the symlink. In my opinion, this is a bug: a symlink is meant to redirect transparently to the target. (For example, the file extension on the target, not the symlink, should determine the language.) All methods of opening a symlink should give the same results.

Hard links are also a problem, but a different one. I think they could be tested using std::filesystem::equivalent. Hard links shouldn’t (and logically cannot) resolve to any other file name, but an editor still shouldn’t allow the same filesystem object to be opened twice, even if it is called by different names. However, that is, at least arguably, an enhancement rather than a bug.

impression its possible for program to handle symbolic links somehow

By “handle”, you seem to mean “ignore their desired intent, and instead dig deep into the belly and circumvent their meaning to impose your own meaning”. Yes, it would not surprise me if it were possible.

But is it a good idea? I don’t know, but I would doubt it.

And is it worth it? Given that I’ve been a member of the Notepad++ Community for 7.5 years, and that I’ve probably read the vast majority of the 75k posts since my first post here, and never seen it requested, I’d conclude it’s a rather niche desire.

But that’s not my decision to make. The only way we’d know for sure would be if someone made an official feature request, as described in our FAQ

And I don’t mean to blame np++ in anyway but I’m under impression its possible for program to handle symbolic links somehow. So maybe there is function somewhere that can translate “symbolic path” to the “root path”.
So maybe it’s possible to improve np++ regarding this? Idk about this, just guessing

the paths are different only filename is same. so its the symbolic link that causes it

Yes, it’s the symbolic link that causes the problem. Because a symbolic link is the contract between you (the user who created the symbolic link) and the OS to (effectively) lie to applications about where the file really is.

The OS is honoring its part of that contract, and so it convinces Notepad++ that the file is at c:\path\to\symlink\file instead of the real path c:\path\to\real\file . Oddly, Notepad++ believes the OS when it says c:\path\to\symlink\file is the path to this file. And thus when Notepad++ searches through its internal list of already-open files, which contains c:\path\to\real\file but not c:\path\to\symlink\file , it says “I don’t have c:\path\to\ssymlink\file open yet, so I will open it.”

Don’t be surprised when the OS honors its contract with you, and Notepad++ takes the OS at its word.

If you want Notepad++ to behave like it’s the same file, either open it using the same path, or use a Windows Shortcut (.lnk file) instead of a symlink (because Shortcut files work differently, and Windows actually tells the application: “I know you said you wanted open c:\path\to\shortcut.lnk, but the path you are really opening is c:\path\to\real\file”)

The fault is not in Notepad++, but in the very definition of what a Windows Symbolic Link is and how it is intended to be used.

dunno where’s the fault at, seems unfixable

Well if you provided more details, we’d be able to tell you if it Notepad++ or not, otherwise, you’re on your own.

the paths are different only filename is same. so its the symbolic link that causes it

Thus, this does not sound like a Notepad++ problem.

@General-Coder

What is the path to each of the tabs that get created? Should be the same if what you say is happening truly is; but this forces you to check…

Use the Window menu’s Windows command to see the paths.

the paths are different only filename is same. so its the symbolic link that causes it

What is the path to each of the tabs that get created? Should be the same if what you say is happening truly is; but this forces you to check…

Use the Window menu’s Windows command to see the paths.

Maybe it’s my C# code that somehow makes the file open twice

I can’t see how that would cause it…

Notepad++ has logic to keep this from happening; if you open an already existing file it should just activate the previously open tab for it, not create another tab (if that’s what you mean by “open twice”).

that’s what I expected to happen, not open it twice

Maybe it’s my C# code that somehow makes the file open twice

ProcessStartInfo startInfo = new ProcessStartInfo();
     startInfo.CreateNoWindow = true;
     startInfo.UseShellExecute = false;
     startInfo.FileName = filename;
     startInfo.WindowStyle = ProcessWindowStyle.Normal;

     startInfo.Arguments = args;

    using (Process exeProcess = Process.Start(startInfo))

if the file i want to open is already open in np++ the file will be open twice

Notepad++ has logic to keep this from happening; if you open an already existing file it should just activate the previously open tab for it, not create another tab (if that’s what you mean by “open twice”).

I think you need to provide more specifics for anyone to try to shed some light on what you’re seeing happen.