PeterJones last edited by PeterJones
For those that are curious, the 2Gb and 9⨯10^18 byte limits for 32-bit and 64-bit come from the fact that the file pointers are 32bit or 64bit integers. Thus, there are 2^32 and 2^64 distinct integers; but because they are implemented (on the filesystem side) as signed integers, and negatives are all relegated to “not applicable to files”, it yields 2^31=2Gb for a 32-bit system, and 2^63=9⨯10^18 bytes for a 64-bit system.
update: sorry, this was started before the most recent posts appeared. Are you saying that 64-bit Scintilla is still limited to 2Gb? Weird.
update2: yep, that thread confirmed 64bit scintilla still limited to 2Gb.
wow, what just happened ? we all came out of nowhere, like piranhas, instantly and simultaneously devouring the same question 😂😂😂👍
The version notepad++ uses - yes, but that is a buffer limit.
You can have multiple files with 2GB if you are running a 64bit Npp and
have enough coffee and cake to wait to get a slot for doing something ;-)
is THIS A DUCATI MONSTER ???
Michael Haigh last edited by
Thank for your kind welcome and response. It looks like I have plenty room yet and it should do what I require. It’s a remarkable editor. I have had a number of crashes (after W10 updates) and find basic Notepad far more reliable for saving (and back up using basic Notepad).
Meta Chuh last edited by Meta Chuh
no it was a ducati street fighter 1099 back then, but i’ve changed to the hypermotard 796 because it’s more comfortable, more drivable for every day use, more agile and the lightest 803cc supermoto ever built in large scale series.
@PeterJones and @Michael-Haigh
edit to my post: technically you should be able to open up to 512mb (524mb) files in a 32 bit notepad++ as @PeterJones mentioned above.
(sorry, i had to read from the bottom up and i was too late to edit my post and mention @PeterJones previous post, already containing the same information)
if you mention crashes on notepad++ with the latest windows 10 updates:
if you aren’t on notepad++7.6.2 already, please download the latest 7.6.2 portable version from here,
(the portable version can reside simultaneously and does not get in conflict with your installed version. any changes made in the portable version will not reflect or change anything in your regular notepad++)
extract it to your desktop, open the extracted folder and run notepad++.exe inside it
open the files, which you remember were open when a crash occurred, and test if it happens again.
if it does not, we know that a vanilla notepad++ will not behave the same and we can start looking at your installed version and it’s plugins to provide a solution.
if it still does crash on you, and you have opened some files on a network drive that could be the trigger, please copy them to your local disk and retest them.
for any further questions regarding your crashing issue, feel free to post them here without opening another thread, as these notepad++ crashes seemed to be the reason why you asked about the file size limit of notepad++ in the first place
chcg last edited by
See https://www.scintilla.org/ScintillaHistory.html Release 3.6.0
- Report error when attempt to resize buffer to more than 2GB with SC_STATUS_FAILURE.
Also N++ uses 3.5.6 i guess that version also has this limit. At least if it should work stable.
For 32bit there was a not accepted PR https://github.com/notepad-plus-plus/notepad-plus-plus/pull/891 to use PAE to extend the limit for the overall mem usage.
… and recent scintilla versions can use even more.
btw @chcg :
(a little off topic, but i’ll wrap it as text limit ;-) )
i’ve tested UCharDet 0.0.6 separately and it detects all test samples correctly, and i can’t find out why, nor understand where the (pretty same) code behaves differently, when implemented into notepad++.
(side note, if it might be something to look at: quite a few users reported, that once detected falsely, you can’t hit “encode in utf-8”, as the bullet jumps right back to the language in “character sets” it has been falsely marked with. you can, however, select “convert to utf-8” and the bullet will stay there. i’ve been able to reproduce this every time)