Sometimes Notepad++ doesn't save even though it appears to.
-
I’m sorry, the icon is blue. It looked gray when it was the selected tab. The file is not read-only.
I am not using dropbox. This is a local-only file in an unshared folder, as normal as normal gets. I am not using any code-monitoring tools that may have opened the file in the background.
Is there a chance that any plug-in is causing this behavior?
-
Is there a chance that any plug-in is causing this behavior?
maybe.
you can test this possibility by downloading the portable version of np++ 7.5.1 from the link below
extract it anywhere (desktop will do) and test with this fresh and isolated install to see if the problem remainsthe portable version allows you to leave your currently installed version as it is and test everything, without external plugins
https://notepad-plus-plus.org/repository/7.x/7.5.1/npp.7.5.1.bin.zip
-
I have exactly this strange problem too in latest version (v7.5.1 Portable)
Sometimes when i edit an existing text file on local HDD and press blue save icon in toolbar (toolbar icon change to gray and red tab icon is changed to blue, that means file is successfully saved) and close program and reopen file again, my added text to file is missed and disappear!
This problem happening on local file sometimes (not Dropbox or any other sharing file) and not any software monitoring running when this problem happend. I using “Notepad++ minimalist package portable” version with just single plugin (CustomizeToolbar)
This is certainly a bug because when happen on one file, when you open that file quickly again and edit it and saving it again, when check it saved true.Is possible or exist any way (Plugin) that i can ensure my file is saved correctly as i see, for fix this bug? (Hash compare or something like that)
More info: (Maybe helped to fix bug)
I disabled “Remember current session for next launch” and in the last two times this problem happen i have opened two instance of Notepad++ and editing two file at the same time.Debug Info:
Notepad++ v7.5.1 (32-bit)
Build time : Aug 29 2017 - 02:35:41
Path : D:\Softwares\Type & Text\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : ON
OS : Windows 8.1 (64-bit)
Plugins : CustomizeToolbar.dll -
Could it be that the files in question are those which do have a 64bit and 32bit version.
There is an issue when using 32bit notepad++ on 64bit windows and trying to edit
64bit files - you get silently redirected to the 32bit version of those files.
If this is the case you might consider the sysnative alias for opening the files.Cheers
Claudia -
This bug is relatively new – it started about a couple of years ago. I ran into it several times today when breaking a big js file (UTF8) into new ones (ANSI by Notepad++'s default). I think it happens when you create a new file within Notepad++, copy some content on it, save, then edit it afterwards. After a while, no changes are commited to disk despite the UI saying otherwise.
Not tested this exhaustively yet. Would be nice if somebody else could confirm this. Thanks.
-
I generally have issues with new files too. What I do is:
- create a new file using Ctrl+N
- type in a tiny bit of text
- use Save As to save the new file with the file location/name I want
- Close the new file without saving it
- Open the file I saved it as.
No problems after that! :-)
-
What I could see:
If you use a file encoded in UTF8 and including accents, no problem.
If I open this file and modify the text by removing the accents, when I save the file and open the file, it is in ANSI.The file is automatically saved in ANSI.
-
If a UTF-8 file without a BOM contains no “accent” characters, then there is no way to distinguish it from an ANSI file.
When Notepdad++ is set to auto-detect the file type, it indicates in the status bar that the file is ANSI. That doesn’t change anything about the file. It is still a valid UTF-8 without BOM file and a valid ANSI file. One is free to call it either!
Edit: change “all” to “call” in the last line above.
-
@Rubem-Pechansky said:
This bug is relatively new – it started about a couple of years ago. I ran into it several times today when breaking a big js file (UTF8) into new ones (ANSI by Notepad++'s default). I think it happens when you create a new file within Notepad++, copy some content on it, save, then edit it afterwards. After a while, no changes are commited to disk despite the UI saying otherwise.
Not tested this exhaustively yet. Would be nice if somebody else could confirm this. Thanks.
Just to add: the problem seems to occur under the circumstances above when you have either multiple instances or files in the ‘Other View’. I haven’t been able to replicate it consistently yet.
Best,
-
welcome to the notepad++ community, @Vinicius-Gottin
Just to add: the problem seems to occur under the circumstances above when you have either multiple instances or files in the ‘Other View’. I haven’t been able to replicate it consistently yet.
thank you for taking the time to report this.
please keep us informed whether you found a way to reproduce it consistently. -
I have steps that are consistent for me to reproduce the issue:
1/ create a new file using the new file toolbar icon
2/ add some text - eg. “This is a test”
3/ save the file - save file dialog appears, save anywhere
4/ add more text - eg. “This is another test”
5/ note that the save button is grey. Try to save with Ctrl+S
6/ close the file
7/ open the file again. Note that the file contains only the first edit eg. “This is a test”. The 2nd edit is not recorded.
8/ Check the backup folder and note that no backup file has been created.Workaround:
1/ follow steps 1-3 above
2/ close and open the file again (or File -> Reload from disk)
3/ use the file as normal. updates are saved as expected.I only have 1 instance of npp open. This happens whether I have other files open or not.
using npp 7.8.6 64bit on windows 10, also tried in 7.8.7 and 7.8.5.
As suggested in one of the above posts, I also tried in npp portable (7.8.5) This version did not have the same problem.
I also tried removing plugins. In my case, removing SessionMgr restores the correct behaviour.
-
So if I understand this correctly, then your analysis indicates that SessionMgr plugin has caused this?
