Fix corrupted txt file (NULL)
After a sudden power outage I found that a couple of my files that were opened with Notepadd++ (Win 10) were corrupted as follows:
I tried many things to open it without any luck, of the thing I tried:
- check to see if there were a previous versions in the file properties (none)
- tried some recovery software, but all just find deleted files
- tried opening the file with other software (Winword, Wordpad, Chrome, Notepad, Safari, Firefox…)
- the backup option was not selected by default in NP++, so no backups
- tried to open the file in Word using the “recover any file tool” - blank
- no hidden files in the folder
The files opens with white spaces (blank) in some software, and shows “NULL characters” in NP++. And when trying to compress the file (8MN, it becomes like 8kb).
Any suggestions are much appreciated.
Now you are more specific.
What is your Notepad++ version?
Where the corrupted files modified (were still unsaved when the power loss occurred) or those were not modified?
I don’t think you can recover the files in any way, sorry, that’s really a nasty situation.
Notepad v7.2.2 (32 bit)
and ya, the files were being modified at the moment of the crash.
OK, can you try to reproduce this on purpose?
Restart your computer, open a single test file in N++, modify it a bit but do not save it.
Then simulate power outage - unplug the computer or switch it off through the button.
Is the file corrupted when you next restart?
I’ll test it myself on my machine and write back.
I just tried that scenario on Linux under Wine, Notepad++ v7.3.2.
The file has zero size - totally empty. So yes, power loss leads to unsaved files corruption.
That needs to be investigated.
I believe that a lot of the “total data loss” postings on this Community can be avoided if people simply turn on the Verbose Backup feature. With this feature turned on, Notepad++ creates a backup copy of the file every time the user saves. This has helped me out on quite a few occasions.
Settings menu -> Preferences ->Backup -> (then Checkmark) Verbose backup
Unfortunate this functionality is also the cause of some problems.
What’s really weird is that, normally, npp opens the file for reading,
once done it closes it and you only work with the buffer in the editor.
No file interaction until you save the file.
I don’t understand how it could happen that a power loss can corrupt the file
if the file hasn’t been opened at that time. And as Pavel was easily able to reproduce
there must be something strange going on. Or, the backup has been enabled and this
was causing it but reproducing it easily doesn’t indicate it.
Hi @Claudia-Frank ,
I agree with you - something is not right, that shouldn’t be happening. The changes should be in memory only and not related to the file content currently on the disk. I did the test with disabled backup. It is possible to be a Scintilla issue.
If I have time this weekend I’ll do some more tests on a native Windows.
At the time of the loss of the file, I didn’t have the backup options on, so it’s not related.
One update - I tried the scenario on native Windows 7 and the issue did not appear.
It’s getting even more weird…
After my latest test under Wine the issue again did not appear.
It seems it is not steadily reproducible which makes it really hard to debug.
thx for your effort.
In the meantime I tried to reproduce by killing the app too and it happened
once out of 10 tries. (after 10 tries I stopped)
Backup disabled all the time.
I searched the source (npp and scintilla part) for FILE occurrences and tried
to understand what happens but none of them give an indication what could have caused it.
Btw. do you cross compile? If so, some hints what I should take care of if I want to rebuild
npp and scintilla on linux?
Hi @Claudia-Frank ,
Thanks for trying that too. It appears to be very tricky issue.
Btw. do you cross compile?
I do cross-compile only my plugins. I haven’t tried cross-compiling N++ but I don’t think that’s straightforward because you’ll need a CMake config (and you’ll have to create one yourself). If you decide to do so you can try automatic conversion from VS solution to CMakeList:
You will also need the cross-compiler (MinGW for x86 in my case).