Notepad++ file content different when opened in Windows Notepad

  • Any idea why the same text file (.js) has different content when opened in Notepad++ compared to when opened in Windows 7 Notepad?
    No matter how much I modify (and save) in Notepad++, file contents won’t change when opened in Windows Notepad (or any other text editing software), even after several days & reboots.

  • Can you be more specific? What is the expected content of the file, and what is actually in there?

  • It’s a JavaScript that runs certain programs on start-up. It was created as a text file, later changed the extension to JS in order to be able to run under windows. I modified it in Notepad++, several times, saved it, several times, but when I come back to it and open the file in Windows Notepad (or any other text editor), the original text appears, with none of the changes made in Notepad++

  • But the changes do appear when you open the file in Notepad++? In that case the only explanation I have is that there are actually two files. In case the changes do not get saved at all, and even Notepad++ displays the old content, maybe UAC is preventing write access to the file. Try saving it somewhere else (such as your desktop) and move it to the target location in Windows Explorer.

  • Hi Did any one get an answer to this I have just noticed the same thing happening on a work built PC,

    If the Batch File is edited on MS Notepad.exe it shows no changes to the the file but if I open and edit in Notepad++ it shows the changes I made to start with If, I run run the batch file is uses the text that can been seen in the MS notepad.exe.

    UAC is not active, users have permissions.

    But my case the issues seems that regardless if I was in opening C:\Windows\System32\Sysprep\Clean.cmd, Notepad++ was opening and editing C:\Windows\sysWOW64\sysprep\Clean.cmd.

  • Im totally not getting what differences you are talking about but here are a few things

    • line endings are changed
    • UTF-8 BOM header (3 characters)

  • @Simon-Harbinson

    as you already figured out, file redirection is the issue here, you could use the sysnative alias to workaround it.


  • Sorry to bring this one up again.
    But surely this is some bug and shouldn’t be written off with some workaround.

    I presume this is only for files in the c:\windows\system32… and opening (any) files in that directory (Or sub-directories) will open the corresponding ones in the c:\windows\syswow32…

    The bug is that it says the file is c:\windows\system32… in the window header but infact it is loading it from c:\windows\syswow32…

    Looking at process monitor when it is running it doesn’t seem to access that file “correctly” (maybe it does procmon gets complex at times)

    result: name invalid

    More research is needed from my side as I am using the 32bit version of Notepad++ on windows 2012r2 installed a while ago but updated to latest one prob with default plugins) maybe 64bit sorts this out.

    Either way symptoms appear real and if you start editing the equivalent files in the c:\windows\system32<anypath and anyfile> and teh same file exists in
    c:\windows\SysWOW64<anypath and anyfile> it will open that syswow32 file up and give you no indication at all notepad++ and will display the incorrect file.

    Also if you try and open files (from file–>open menu) in the system32 folder in notepad++ it displays all the files from the syswow64 folder.

    Seems really messed up. And caused me no end of headaches.

  • @John-Baker

    not sure if this will be fixed in the 32bit version at all, as the 64bit version has been already
    introduced, which doesn’t have that issue, and more and more plugins get a 64bit version as well.
    So I assume the 32bit version will die on 64bit OSes as soon as most of the plugins are ported to 64bit.


  • OK so 64bit you say is OK and has been released now. That makes sense and I understand the focus on that 64bit OS. It would be nice however to release a 32bit fix for it.

    I am confused why it shows what it does in 32bit and as I said seems like a bug where it seems to wrongly calls the paths and “default” to the wow64 folder.

    If you want to fix it and require a more detail explanation please let me know.


  • @John-Baker

    If you want to fix it and require a more detail explanation please let me know.

    the issue itself has been already opened and is labeled as enhancement but as said, I don’t know if Don will spend more time in investigation and fixing.
    Personally I think it doesn’t make much sense but who knows, maybe he will do it.


Log in to reply