Find in all files
Hello, when using the Search & Search in all files option with the Notepad ++ program, when it comes to folders with 2.5GB files (without any notification), the program automatically closes.
Your old versions were also warning, but the program was freezing.
I understand that it doesn’t search for the file, but isn’t it brutal that the program suddenly quits instead of skipping the large file after 50 minutes of searching?
Most likely Notepad++ crashed and did not close.
So that is not a design decision of the developers to close but rather a bug need to be fixed.
In the past Windows would have given an explicit message when an application crashed but Microsoft decided to turn it off so users will not be confused by it. Please send Microsoft your sincere thanks for not being confused.
Thanks for reply, now in version npp.7.5.9 (the file is too big) I see an error message and “after clicking OK” it the program continues to run.
Please, provide more info on Notepad++ version and your OS.
Also, you can try creating an issue here if it’s still a problem in the current version of Notepad++.
Notepad++ v7.5.9 (64-bit)
Build time : Oct 14 2018 - 15:19:55
Path : C:\Program Files\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 10 (64-bit)
Plugins : DSpellCheck.dll mimeTools.dll NppConverter.dll
The current version (7.9.2 , 7.9.1 , 7.9 etc ) does not give any warning and crashes when you encounter a large file during the search.
i can handle using 7.5.9 version, there is no problem in this version right now.
I tried searching in a directory with game files (StarCraft ll) and it crashed after consuming ~20GB of RAM.
@mere-human Try v7.5.9 and reply please
Created an issue https://github.com/notepad-plus-plus/notepad-plus-plus/issues/9456
Also, there is a similar issue about restricting search only to text files: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/9445
@Mrr-Jack Will try tomorrow maybe.
I didnt apply any filters.
There is a 4.5 GB .ost (office) file in my files.
It crashes probably because of this file.
MS Outlook’s offline email file (.ost) are not text files. You should not be using Notepad++ to try to search proprietary binary data formats. Exclude binary files from any Find in Files searches you make.
If you don’t want Find in Files to even try for such binary files, then you need a relatively-recent Notepad++ (v7.8.2 or newer), and you can use FILTER =
*.* !*.ostto include all files but not search any .ost file. Or, if you really just want to look at certain file types, doing a filter like
see the Find in Files docs section at https://npp-user-manual.org/docs/searching/#find-in-files
You should not be using Notepad++ to try to search proprietary binary data formats
I didnt apply any filters.
I would guess a LOT of Notepad++ users do this (perhaps unintentionally), because they want to search a directory full of files, but only care about hits in certain ones. They ignore what they don’t want in the visual results. They do this because it is too much trouble to specify an include/exclude filter. Or, they simply don’t know about the exclude feature, or possibly there are directories in the tree that are not reasonably possible to exclude. All of these situations could lead to searching a large stray binary file that might cause a crash as being discussed in this thread. :-(
@PeterJones Thank you for the answer.
As I said, I was searching without adding filters until now, there was no crash.
After that, I will definitely apply filters, but as i mentioned before, new versions crash because of this, but the old versions notifies us of the obstacle that occurred during search.
So whatever happens, it does not mean there is no problem. Whether to fix it is up to you
Whether to fix it is up to you
Nope. The Notepad++ Community forum is a forum of the user-community of Notepad++, helping each other. This forum is not the official way to contact the developers to request changes to the codebase. I am not a Notepad++ developer (though I have contributed a commit or two to XML config files, IIRC); most of the people who have replied in this topic are not Notepad++ developers.
The real sequence of events:
- @Mrr-Jack mentions a problem in the forum
- Individuals from The Community and @Mrr-Jack work together to confirm or contradict @Mrr-Jack’s original report
- If enough proof can be gathered that there is really a problem with Notepad++ when used as intended, then one or more of the Community will likely recommend that @Mrr-Jack read the FAQ that explains where to make Bug Reports or Feature Requests
- If @Mrr-Jack so chooses, he can follow those instructions to submit a bug report. If an official request is submitted, then it is up to the development team (and in the end, up to the lead Developer, Don Ho) whether or not the fix will be made and Notepad++ updated.
We are still in step 2.
it does not mean there is no problem
So far, the only evidence is that undefined behavior has changed. I say this because so far, all that we’ve seen is that when a humongous non-text file is part of the search directory, and the user chooses not to exclude that invalid file from Notepad++'s text-only search, a crash now exists that didn’t exist before. But trying to search non-text files has never been an intended use of the Notepad++ Find in Files, and anyone who was using it that way was using it in ways not intended, with no guarantee that it would behave in a meaningful way – or that the unintended use would work the same from one version to the next. Whether or not the end behavior has changed, the root cause of the problem is using Notepad++ in a way it wasn’t designed to be used.
Let me try to put it as an imperfect analogy: Consumer C has always incorrectly used his screwdriver 1.0 as a prybar to remove nails from a 2x4 piece of lumber, and it has always miraculously worked for him, even though it’s not the intended use of a screwdriver. Now Consumer C gets a new version of the screwdriver 2.0, which has a removable handle so it can swap to one of 10 different screw bits. When Consumer C now tries to use the screwdriver 2.0 to pry up a nail from a 2x4, but instead of doing what other screwdrivers have always done, the screwdriver handle breaks and falls off. When Consumer C contacts the screwdriver manufacturer, they aren’t going to redesign the screwdriver 2.0 just because it doesn’t work as a nail puller; instead, they will explain to Consumer C that he has been doing it wrong, and that the upgrades in screwdriver 2.0 mean that it is less forgiving of misuse, and then explain ways to properly use screwdriver 2.0 as it was intended.
If you can show that Notepad++ used to be able to Find in Files in a hierarchy which contained huge text files, but now it crashes, then great, you’ve found a real bug, and we will encourage you to fill out a bug report. But if you are trying to search a binary non-text file using Find in Files, Notepad++ does not guarantee the results of that undefined activity, and I doubt that even if you submitted an official bug report that it would gain much traction. But maybe I’m wrong, and the developers would try to mimic their undefined behavior from before in a future revision of Notepad++ if you asked them to. But I am not the one who decides. The generic “you” of readers of this topic and forum are not the ones who decide. The developers who are responding to an official bug report are the ones who get to decide. And so far, there hasn’t been an official bug report.
@PeterJones I guess you didn’t understand me, or you don’t want to. I was unsure between these two.
You don’t need to teach me how to use the program or talk about hammer nails @PeterJones.
I have stated that in the old versions (even if there is a usage error) the program did not crash, it gave a warning in the anormal state . @PeterJones
While I was bringing up the subject , i was not aware of why this situation was happening @PeterJones. Because it was closing directly without any notification. As time progressed, I resolved the situation and stated here . @PeterJones
I hope you understand me now @PeterJones.