NPP Erasing all or part of a file changed while open
-
I use Notepad++ (currently at v7.7.1 32 or 64 bit on Windows 10 x64) to display and edit INI files quite a bit. Recently I have started seeing the INI file content vanish after the program that ‘owns’ the INI updated it while NPP had it open. This is happening on multiple machines and (so far, at least) we have only ever seen it when NPP has the file open when it is modified externally. Sometimes, everything below the current cursor location is removed, but most times the entire file content is removed when we allow NPP to reload. This is a recent issue (within the past month or so). As long as we remember to NEVER leave files open that might be modified outside NPP, all is well, but we really wish it worked as it did in the past.
-
not 100% sure I understand your issue.
Notepad++ opens a file for reading and once it has read everything it closes the file.
From now on, you work with a memory copy and only if you press save it will be written
to disc.
Now I understand, that it happens to you that after npp loaded a file and this file gets changed externally that npp looses the whole content, right?
But the file still exists, correct? And it still has the content from the external change operation, correct? -
After NPP pops the message telling me the file has changed and asking if I want to reload, the file content ON DISK will go away when I say reload. NPP shows the file as empty and the disk image is also empty according to Visual Studio 2019 when I try to open the file there. This could be a Windows thing, but I have not yet experienced it with any other program that reports external changes to files (e.g. Visual Studio 2019), so NPP seems best place to start.
-
Okay, I guess I understood now.
I would give it a try to do the following.
Once you receive the message that the file has been changed, do NOT confirm the reload but
check with another program if the file has been already erased/changed (that’s what I assume).
If you can force this scenario, then I would suggest to use procmon and see what is really happening at that moment. -
I just saw your most recent suggestion after observing a new detail that I had not noticed earlier:
I opened INI file in NPP after the program that uses it read the file (using calls to GetPrivateProfileString – NEVER by actually opening the file itself [it is my code, so I am certain of this]). Then I changed the file and saved the changes. The save caused my program to re-read the file, again using GetPrivateProfileString. About one minute later, I made another change in NPP and tried to save the file, but I was told that the file was locked and given the option to save with a new name. When I looked at the file in Windows File Manager, the size was reported as ZERO. When I returned to NPP, it popped up the “file has changed from outside” notice over the unanswered “file is locked prompt.” I chose not to reload the file from disk and then chose not to save with a new name. Then I tried to save again and it worked fine.
Oh, in case you wonder, I actually have some timing measurements from my code and it spends less than a second reading the INI file content. I cannot say how long Windows keeps the file locked in case I try to read another line, though. Perhaps NPP is somehow clashing with that now when it never seemed to happen before?
-
did you ever notice that npp reported something like file has been updated before using npp 7.7.1?
I’m wondering if you just have not used this feature and therefore never noticed this?
The feature itself is configurable via settings->preferences->misc and choosing
one of the values from file status auto detection.As you can force this issue, I would try to use procmon with a filter set to your file.
Then you will see which process opens, modifies and closes the file in which order. -
@Steve-Valliere said:
GetPrivateProfileString
GetPrivateProfileString does “open” the file. The last argument is the filename in which to search for the string.
Also, does your code save to the file using WritePrivateProfileString?
Cheers.
-
@Ekopalypse I have not only noticed that behavior, I tend to RELY on it.
I will look into getting this to happen with procmon running.
-
@Michael-Vincent I know that GetPrivateProfileString is opening the file. I also know that my program DOES NOT open the file itself using anything except GetPrivateProfileString. That is why I wondered how long Windows was and is keeping the file open/locked after the last get was performed.
My program can use WritePrivateProfileString if the configuration editor component is invoked, but I am not doing that during this testing in order to ensure that my program is NOT modifying the file in any way.
-
@Ekopalypse OK, according to procmon, when the “file is locked” message appears, EXPLORER.EXE was the last thing to access my file. Aside from the desktop itself (and my file is NOT on the desktop) I have only one explorer window open, focused on the folder where the procmon.exe program was downloaded, extracted, and run. Regardless, Explorer apparently decided to access my file with a ‘QueryDirectory’ operation (again, according to procmon). The filename is “ev11.ini” and the detail for the Explorer access reads “Filter: ev11.ini, 1: ev11.ini” – I have no idea what that means. But if I access the changes that are announced by NPP just after this, the file will be empty (and is empty on disk while the “is locked” message from NPP is visible. I cannot explain it, I can only observe and report.
-
your code that modifies the ini file, is this something you can share?
If not, can you share the exact steps in this code so that I can create
it to see whether I can see the same behavior and maybe understand
a little better what is going on?My current problem of understanding is that, from my point of understanding, a file can only
be modified if it has been opened with write privileges and npp doesn’t do this in your provided scenario.
But of course I respect your info that this didn’t happen with earlier versions,
it’s just that I don’t see how npp is jumping in here. -
I can share it, but it is NOT being called in the scenario I have described. I have a breakpoint in the Visual Studio debugger when any call to WriteProfileString is made and it is not being hit. I am NOT activating the configuration tool, which is the only thing that even CONTAINS calls to WritePrivateProfile string. What my program IS doing, is monitoring the directory for changes and calling GetPrivateProfileString (many times) after the file was changed with NPP.
The issue seems to occur if I make ANOTHER change with NPP and try to save within a few minutes of my program re-reading the INI file. That is RE-READING.
If I look at the directory when NPP reports that the file NPP just tried to modify was locked, the file size shows as ZERO and trying to use ‘type’ to view the content at a CMD prompt shows the file is empty. The content will be “magically” restored if I tell NPP to give up writing to the file, and NOT to save with a new name and then tell NPP NOT to reload the file after NPP (erroneously, IMHO) reports that the content changed.
If the file content changed, NPP did it. I’m afraid I am not likely to believe that Windows File Explorer is changing the file content, and I can prove my program isn’t writing to it, both by using procmon to see that the only write operations come from NPP, and by using the debugger to catch any attempt to call the write functions.
