Notepad++ v6.9.2 released

[PeterJones]

@Gilad-Danneboom,

Please note that “that does not work for me” does not provide much information to the people who are trying to help you debug your issue. The fact that it does the same thing when you downgrade from 6.9.2 to 6.9 shows that it’s not just a specific version of the software – and hints that it might not be on Notepad++ end at all. My default, when asking for help, is to be as verbose and detailed as possible; sometimes there is extraneous information included, but that’s better than not including enough. There have been many people (easily hundreds, probably thousands) using NPP 6.9.2 with the majority of files being properly saved.

Those that weren’t saved, in my experience (and as Claudia and I have said, previously) were because it was an issue with the way that Windows handles 32bit apps trying to access certain directories that are 64bit-specific. Thus, our debug attempts were pointed in that direction. But there’s another two circumstances I thought of that have similar behavior: 1) trying to edit a Notepad++ configuration file: those files will be overwritten when NPP exits, so your changes will be overwritten. 2) If the file is open in another process (Word, Excel, web browser, etc), or can be written to by some background process (a .log file, a database application, etc), maybe the file is being overwritten by something else after you’ve saved the changes.

But now I will admit, I failed you in my first debug attempts: I made the assumption that since your brief problem description sounded like (gave the same symptoms as) the filesystem redirector, I thus assumed you were trying to edit a file somewhere in %windir%\System32 (or a subdirectory thereof; note that %windir% is the variable-notation for the main windows directory; on windows 7, it’s often c:\windows, but not always; thus, %windir%\system32 will be c:\windows\system32), and only went in that direction in my responses. But I now see that no one has clarified the file’s location, so this could be wrong.

The following are the series of steps I would take if the problem were happening to me. If you share the results of the steps (more than just “it doesn’t work”), you might be able to find the problem, or we might be able to help you find the problem. My two major sections of debug that I will describe below “what version of stuff am I using and what exactly am I looking at?”, and “making the same assumptions that PeterCJ was using, why would %windir%\sysnative not be working for me?”: the second group only applies if the file really is in the %windir% hierarchy.

What Version of Stuff Are You Using? and What Exactly Are You Looking At?

• Does it do it with all files, or just some? What’s the same (or different) about the files that work vs the files that don’t?
• What is the exact sequence of events that you use to edit, save, and discover that it’s not saved?
  • How do you load the file in Notepad++?
  • How do you save the file?
  • How do you confirm that the file actually saved?
  • Do you close Notepad++ at this point, or just close the file from Notepad++, but leave the application running?
• What are the results of the following: From notepad, Notepad++ choose ? MENU > Debug Info > Copy debug info into clipboard (paste it in your response, indenting by 4 characters to make it a block of preformatted text)
• Have you verified 64bit OS?: START MENU > RightClick on Computer > Properties: what does the System section say the System Type is?
• What is your %windir%: Open a command window ( START MENU > cmd.exe or WINKEY+R then cmd.exe), and type echo %windir%, what gets printed?
• What is the full path of the file you are trying to edit that fails?
  • If it’s in the %windir% hierarchy, it’s probably because of the filesystem redirector
  • If it’s a Notepad++ configuration file, NPP will overwrite the file when it closes

If you do not have a 64 bit OS, stop here, as we will have to process the new information before further debug is possible.

If your file is outside of the %windir% (c:\widows or equivalent), stop here.

---

%windir%\Sysnative debug

Since you’ve continued this far, you are confident you are on a 64bit OS and that the file is somewhere in the %windir% hierarchy. Thus, we need to determine why the sysnative alias does not appear to work for you.

1. Open a 64bit cmd.exe: WIN+R > %windir%\system32\cmd.exe
   1. note, when I do this, it opened in c:\windows\system32
   2. echo %PROCESSOR_ARCHITECTURE% => should give AMD64 or similar
   3. echo %PROCESSOR_ARCHITEW6432% => should be undefined, so it will just print %PROCESSOR_ARCHITEW6432%
   4. dir %windir%\system32\cmd.exe %windir%\syswow64\cmd.exe => these should give different filesizes
   5. dir %windir%\sysnative\cmd.exe => should tell you it doesn’t exist
   6. echo DEBUG64 >> %windir%\system32\DEBUG64.txt
   7. echo DEBUGWOW >> %windir%\syswow64\DEBUGWOW.txt
   8. remember to copy/paste your results into your response
   9. close the 64bit cmd.exe window
2. Open a 32bit cmd.exe: WIN+R > %windir%\syswow64\cmd.exe
   1. note, when I do this, it opened in c:\windows\syswow64
   2. echo %PROCESSOR_ARCHITECTURE% => should give x86 or similar
   3. echo %PROCESSOR_ARCHITEW6432% => should give AMD64 or similar
   4. dir %windir%\system32\cmd.exe %windir%\syswow64\cmd.exe => these should give the same filesizes (which match the syswow64 version from 1.4, above): %windir%\system32\ gets magically redirected
   5. dir %windir%\sysnative\cmd.exe => this should give a different filesize than 2.4; it should be the same as the system32 version from 1.4, above.
      • if this one says “No such file or directory”, then there is something wrong with your computer’s sysnative alias
      • if it reports the expected value, we can continue
   6. echo DEBUG64_WILL_GO_INTO_WOW_DIR >> %windir%\system32\DEBUG64.txt
   7. echo DEBUGWOW_FROM_32BIT >> %windir%\syswow64\DEBUGWOW.txt
   8. echo DEBUGNATIVE_FROM_32BIT >> %windir%\sysnative\DEBUGNATIVE.txt
   9. cd %windir%\sysnative
      • dir DEBUG*.txt => should find DEBUG64.txt and DEBUGNATIVE.txt
      • type DEBUG64.txt => “DEBUG64”
      • type DEBUGNATIVE.txt => “DEBUGNATIVE_FROM_32BIT”
   10. cd %windir%\syswow64
       * dir DEBUG*.txt => should find DEBUG64.txt and DEBUGWOW.txt
       * type DEBUG64.txt => “DEBUG64_WILL_GO_INTO_WOW_DIR”
       * type DEBUGWOW.txt => “DEBUGWOW\nDEBUGWOW_FROM_32BIT”
   11. cd %windir%\system32 => trying to cd into main, but really will be syswow64
       * dir DEBUG*.txt => you might expect this to be the system32 contents (similar to sysnative above), but it will actually be the same results as syswow64.
       * type DEBUG64.txt => “DEBUG64_WILL_GO_INTO_WOW_DIR”
       * type DEBUGWOW.txt => “DEBUGWOW\nDEBUGWOW_FROM_32BIT”
   12. remember to copy/paste everything into your response
   13. close this 32bit cmd.exe window
3. Open Notepad++ 6.9.2
   1. File > Open
      • type in the File Name box: %windir%\syswow64\DEBUG*
      • you should be able to see the same files as listed in 2.10, above: DEBUG64.txt and DEBUGWOW.txt
      • use CTRL+CLICK on the two files to open both simultaneously.
      • The contents should match 2.10
   2. File > Open
      • type in the File Name box: %windir%\system32\DEBUG*
      • results should be the same as 2.10, 2.11, and 3.1 above.
   3. File > Open
      • type in the File Name box: %windir%\sysnative\DEBUG*
      • available files should match 2.9, above: DEBUG64.txt and DEBUGNATIVE.txt
      • CTRL+CLICK to open both files
      • the contents should match 2.9.

As one possible solution, as has already been pointed out, you could just download the 64bit Notepad++ 7.0 candidate (see the thread NPP 7 Release Candidate for the download locations).

[Gilad Denneboom]

@AdrianHHH
I appreciate the need for exact details in order to solve a problem. I’m usually on the other end of the “negotiations”, trying to get relevant information from users with problems. As I said, I’m happy to answer any specific questions asked regarding the problem, but I was not asked any such questions until Peter’s latest reply…

@PeterCJ-AtWork
Thank you for the detailed reply and instructions.
When I first re-installed 6.9.0 it was over the 6.9.2 version I had and then the problem persisted. Since then I uninstalled NPP, manually removed its folder from Program Files with all the left-over files that were there, and then re-installed it (6.9.0). The problem has not re-occurred since then (knock wood). So I don’t know if answering all of your questions has any point now, since the problem seems to be gone.
Just to clarify:

• The files I was opening where this problem happened were not located under C:\Windows, they were also not NPP configuration files, but files created by me, located under my own folders on the C drive.
• I was opening them via the File menu of NPP, and maybe also by double-clicking them in my file manager application, can’t be sure exactly.
• I was saving the files using Ctrl+S in NPP.
• I confirmed they were saved because their title changed from red to black and I was not prompted to save them when I closed them.
• I noticed this happening while NPP was still running. It might have also happened between sessions when I re-opened a file after closing NPP down (along with the entire computer), but can’t be sure of that, either. As I wrote, this did not happen all the time, so it was very difficult to keep track of the exact circumstances when it did.
• System type is 64-bit (Windows 7 Home Premium)
• %windir% is C:\windows

Thanks for your support so far, Gilad.

[guy038]

Hi all,

I didn’t follow this topic, But I noticed something strange, in the last Gilad’s reply !

Gilad said, in his previous post :

I confirmed they were saved because their title changed from red to black

AFAIK, when the file status is “saved”, the colour should be blue, shouldn’t it ?

Best regards,

guy038

[Gilad Denneboom]

@guy038
Sorry, I meant blue… Didn’t double-check it, it was from memory.

[PeterJones]

@Gilad-Denneboom ,

I am glad that the problem hasn’t re-occured since the fresh re-install. But that clue could give insight into the cause: it may be that some specific configuration setting or plugin was different in your 6.9.2; when you downgraded overtop of the old installation, that setting or plugin remained, but when you deleted and reinstalled, you removed that setting.

You probably don’t want to spend more time on it, but this is what I would suggest if you ever need to debug the problem again, instead of just hoping 6.9.0 will continue to work for you. I’d grab the ? > Debug Info from this working setup, move all of the Notepad++ 6.9.0 directory to a backup location; install 6.9.2, and see if it starts happening again. If it does happen, I would look at the 6.9.2 ? > Debug Info and the config files and plugins, and try to determine what’s different. If just a simple compare didn’t give enough insight to finish the debug, I’d archive 6.9.2 to a backup location as well, do another clean 6.9.0 install, and start copying things, one at a time, from 6.9.2-backup to the “test” installation.

Other debug ideas I had: use the Notepad++ File > Open Containing Folder > Explorer to open an Explorer window in the folder it’s actually editing from; then, after hitting save, watch the file’s timestamp and size change (and maybe even record it somewhere). Then, the next time you open the file and it’s not the most recent edit you saved, you can open the local Explorer again, and see if it perhaps regressed backward in time, or if it was somehow edited again after you’d saved the last time.

But, like I said, either are probably more than you want to do while it’s working. I’m glad it’s working, and hope it continues for you.

[Gilad Denneboom]

@PeterCJ-AtWork
I actually suspected that the plugins might have something to do with it, so when I did a fresh installation the only one I kept is Compare. Previously I also had Session Manager, Bookmark Manager and XML Tools, I believe. Maybe that helps…

[Daniel Carter]

@Claudia-Frank
Yes the files i am trying to monitor are not in the root directory.

[Josh-D. S. Davis]

@Gilad-Denneboom said:

Just to clarify:

• The files I was opening where this problem happened were not located under C:\Windows, they were also not NPP configuration files, but files created by me, located under my own folders on the C drive.
• I was opening them via the File menu of NPP, and maybe also by double-clicking them in my file manager application, can’t be sure exactly.
• I was saving the files using Ctrl+S in NPP.
• I confirmed they were saved because their title changed from red to black and I was not prompted to save them when I closed them.
• I noticed this happening while NPP was still running. It might have also happened between sessions when I re-opened a file after closing NPP down (along with the entire computer), but can’t be sure of that, either. As I wrote, this did not happen all the time, so it was very difficult to keep track of the exact circumstances when it did.
• System type is 64-bit (Windows 7 Home Premium)
• %windir% is C:\windows

I’ve been fighting this issue for a while too, and have had trouble finding a solution.

The Jist of it is, in some situations, NPP will think the memory buffer has not changed, even though it has. If NPP thinks no content has changed, it will not write out a file.

The expected behavior is, if I use ^S, or Alt-F+S, or mouse over to File -> Save, then the file should be written out, no matter whether it has been modified or not.

However, if I save a file, wait 10 mins without modifying the file, save again, the modification time is 10 mins ago. This is a deviation from everything I’ve seen for editors of all types over the last 35 years.

This has shaken my confidence in NPP as a whole, because save means “write to disk”, not “maybe write to disk.”

My reproduction steps are:

• Use ^N to create a new file
• Add some text
• Wait a while (minutes? Hours? Depends on the project)
• Alt-F + S to file->save (desktop, or E:\Documents, or anywhere)
• Wait a while (minutes? Hours? Depends on the project)
• Add more text
• Alt-F + S to file->save
• Alt-F4 Close NPP
• Re-open NPP
• First save of the file is shown.
• No backup files in the backup dir

INTERMITTENT

• For me, it’s not 100%, but it happens enough to be a serious problem.
• It’s not isolated to any specific drive or folder.
• It may be a timing thing. Unfortunately, I usually don’t notice it until after the data is lost. I close for a reboot, or windows search across my worklogs only to find data is missing, or file timestamps have not changed.
• I do not recall ever seeing it happen if I open a file, and then do edits. Only when it started life as a new file, and during that first time to be open.
• For all I know, every file is unlinked and relinked by some unknown process, and maybe NPP is just writing back to a stale filehandle, or overwriting an unlinked file.

Workaround:

• Close and re-open the file. Now everything will work properly, as long as I still have the data to add to the file.
• Only works if I suspect, or notice the red bar has stopped working, or if I remember to make a file, save it, close it, then re-open it.

HISTORY:

• This started this year, but I do not know what version. Prior to 6.9.2.
• I originally had the PortableApps version.
• I moved to the full installer once an autoupdate brought this issue.
• I’ve uninstalled and reinstalled NPP.
• I’ve wiped and reloaded my laptop entirely.
• I have the issue on a system that never had the PA version.

MULTIPLE SYSTEMS:

• Customer issued laptop
• Work laptop from last year
• Newly reinstalled work laptop from this year.

RELATED:
NPP also periodically sees that all of the open files have been changed (they have not. Same timestamps). I do not know if that is related. Maybe it’s a Google Drive thing, or an MSE thing, or something else entirely. Does not happen daily.

My current test is:

• Saved my session
• closed NPP
• wiped C:\Users\jdavis\AppData\Roaming\Notepad++
• re-installed NPP
• re-configured NPP
• Set my shortcut to “run as administrator”
• Imported my session

DEBUG INFO
Notepad++ v6.9.2
Build time : May 18 2016 - 00:34:05
Path : C:\Program Files (x86)\Notepad++\notepad++.exe
Admin mode : ON
Local Conf mode : OFF
OS : Windows 7
Plugins : mimeTools.dll NppConverter.dll NppExport.dll PluginManager.dll

[Claudia Frank]

@Josh-D.-S.-Davis

this basically means, that you manually save the file(s) each time you change it
and in addition you have automatic backup enabled to let npp do it, correct?
Sounds strange, indeed.
Did you thought about using procmon to find out what’s going on?
Set either a filter for npp exe or for a file you are curently using,
maybe this points you in the direction of the issue.

In regards to the second issue procmon could be helpful too. I assume this
has something to do with samba, cifs etc… setup.

Cheers
Claudia

[Josh-D. S. Davis]

@Claudia-Frank all local NTFS, no network filesystems.

I’ve pulled down procmon, but usually, I don’t notice the problem until after I’ve closed NPP. It’s on the re-open that I notice most.

When I have noticed it, I would type in the NPP window, and the tab would not turn red.

However, deleting the NPP directory seems to have resolved the issue. I’m not sure though. I’ll come back if it resurfaces, and hopefully I can catch it with procmon.

[Faust Jonson]

hi everi one