Fix corrupted txt file (NULL)

  • Glad to see this is still an issue 3 years after being reported. I just ran into this problem when saving and then closing the laptop lid that initiated a reboot because how else is Windows suppose to destroy your data. I will be taking this opportunity to never use notepad++ again. Thanks.

  • I am sorry to say that I cannot tell you a way to fix the corrupted files. But what I can tell you is this isn’t npps fault,
    The culprit is Windows itself. Turn this off to avoid future losses. I lost my 7 days of work to this.
    ![The culprit](6e1d09b6-f495-4cd5-91d0-4cc3badf811e-image.png image url)
    The solution:
    ![Solution](007a186c-4e3a-4331-8d1a-72507d93e965-image.png image url)

  • @Afroja-Noon ,

    You are right, although Notepad++ can use the appropriate Windows APIs to flush the write cache when saving and circumvent this.
    The common user is not obliged to know such details and deal with system configuration nonsense before doing a simple text editing.
    If I were an uninformed user and lost my saved data edited in Notepad++ I would loose trust in the editor too.


  • @pnedev said in Fix corrupted txt file (NULL):

    although Notepad++ can use the appropriate Windows APIs to flush the write cache when saving and circumvent this.

    @pnedev, were those the changes you have committed as referenced in #6133? Were any or all of those changes incorporated into the codebase? (I see that #6164 was closed, but more changes were made after that, so I’m not sure the rest of your fixes were ever incorporated.)

  • Hi @PeterJones,

    Yes, is the PR that should fix this problem but as Don decided to reject it it is not merged but simply closed.
    The later changes perhaps appear because of the patch re-bases in my Npp code clone (
    This is because I have mentioned the issue numbers in the commit message.


  • I solved my corrupt file with Recuva software after a blue screen in windows, I followed the instructions in the following post: and voila!! Thanks


  • @Christina-Toumanidou Nope. Doesn’t work.

  • This issue is STILL happening in 2020 under NotePad++ 7.8.5 ! We just had a power outage and upon reboot everything was fine (11 open files) except for the current file I was working on. I just lost 5 hours of work. I hit CTRL-S almost every 10 seconds when developing. 163KB code file filled with NUL characters, this is insane!

    For the record:

    • Backup on save was set to “None”.

    Here’s what NotePad++ shows when opening the file:


    Here’s what Recuva gave me, absolutely useless. F*** !!!


    I cannot believe this is happening to me right now. 5 hours of work destroyed for no reason. This isn’t 1991 anymore. WTF?

  • @Ben said in Fix corrupted txt file (NULL):

    Backup on save was set to “None”.

    But session snapshot and periodic backup is set?
    If so, then it might be that the real files are still valid and
    only the temporary files have been corrupted.

    I hit CTRL-S almost every 10 seconds when developing

    Which then can mean, that your data loss is only for the last ten seconds.

  • @Ekopalypse

    OP said:

    I hit CTRL-S almost every 10 seconds when developing

    Doesn’t this imply that the user is working with a file that is NOT subject to periodic backup, but only subject to backup-on-save?
    My understanding is that only unnamed files are subject to the periodic backup.

    But then OP says

    backup-on-save was None.

    So to me this means that there was only ONE version of the file, and if it is corrupted, then, well, sadly, there isn’t anything to recover.

    This also says to me that there is still a data-loss problem with Notepad++…

  • @Alan-Kilborn said in Fix corrupted txt file (NULL):

    Doesn’t this imply that the user is working with a file that is NOT subject to periodic backup, but only subject to backup-on-save?
    My understanding is that only unnamed files are subject to the periodic backup

    No, Npp creates for every unsaved file a backup.

    backup-on-save was None.

    Is just an additional option, afaik.

  • @Ekopalypse said in Fix corrupted txt file (NULL):

    Npp creates for every unsaved file a backup.

    I don’t find this to be true.
    Change my mind! :-)

    But start with a definition of “unsaved file” because this is ambiguous and could mean either:

    • a file that has never been user-saved, and typically has a name like “new 3” for example, but could be renamed (without disk-saving) by the user
    • a file that has been user-saved (to disk) at least once, but currently is modified/dirty (red disk icon)

  • @Alan-Kilborn

    The definition is, at least for me, correct and your explanation
    is correct too.
    What am I missing?

  • @Ekopalypse

    Maybe I/we got off track from the context of the OP’s problem.
    I’m supposing that the OP at the start created a new file and immediately gave it a disk-name, then continued working with the file.
    After doing that, there is no periodic backup automatically done on that file by Notepad++.
    So your advice to the OP about temporary files versus real files confuses me.
    But I can get out of the conversation.
    I will just listen and see if we get any more info from OP about the data loss.
    Obviously as a user of the product, I am always worried about my own data when I read such thread.

  • @Alan-Kilborn

    I’m confused as well.

    Assuming the configuration is like this


    I use new 1 and type some nonsense text.
    At this point I will have a backup new 1 file which this content


    Now I save it with the name D:\nonsense.txt.
    The new 1 backup file is gone and there is NO d:\nonsense.txt backup. Now I’m going to change this file and voila


    So, what did I miss?

  • @Ekopalypse

    Your explanation is correct.
    Without going into detail, my ramblings are just garbage. :-)
    I just have ways of working with N++ that are way safer than some things N++ allows you to do, and I tend to forget how some of these things work for others that don’t operate as safely. :-)

  • Yes, periodic and session backup option was set.

    FYI, my file was not a new tab (a.k.a. “New 1”). It was a file that I first created 2 months ago. It’s an old file that I edit daily. But to answer your question: No, under AppData\Roaming\Notepad++\backup and even under the local program file folder Notepad++\backup there are many files, but not that one :(

    I am still running Recuva scans with various filters right now… and come to think of it, I now realize I could have had a chance of recovering a very, if not the most, recent version of that file, since I had viewed it in the seconds prior to the power outage, but since I launched Firefox immediately after powering on the computer (after the power outage) the cache2 folder probably was flushed.

  • @Ben

    No, my point was that the NULLs file you saw is the file from the backup directory but if there is no file in the backup directory then
    it might be that the real file has been corrupted.

  • How is that even an hypothesis? I’m literally double clicking the file from the Windows explorer and it shows up as NUL. Even opening it with an hex editor or Firefox reveals only NUL characters. It’s not the cache/backup file that’s corrupted, it’s the damn “real” file.

    The fact that NotePad++ in 2020 (!!) DIRECTLY OVERWRITES the “real” file when saving instead of writing the buffer to a new location on the hard drive, verifying the write and THEN switching the OS file handle completely blows my mind.

  • @Ben ,

    I am sorry this is still happening. We in the forum report this issue as often as we can.

    I have poked my existing issue #6133, but @donho rejected @pnedev’s #6164 last fall because of possible regression issues. I have asked @donho to respond with a list of criteria for an acceptable PR. Maybe if he gives that list, @pnedev will be able to make a PR that makes @donho happy.

    That said, even if it switched over to using the Win32-API with its flushing capability, it’s no guarantee that the Windows OS will always handle things correctly when it gets Win32-API calls. The best bet, even if we can get this fixed in the application, is to not only save often (which is excellent behavior, by the way, and I applaud you), but also keep backups of critical data in as many ways as possible. At my work, critical data is always supposed to be saved to a file in our corporate cloud data storage, as well as backed up with our live incremental backup software (which should update any saved file within about 15minutes of its last save); further, anything that has an incremental nature in my mind (software development, schematic development, and the like) also gets frequent commits to a version-control repository.