Version: (using KDE 4.2.0) OS: Linux Installed from: Gentoo Packages When I open A file in okteta which is of 6gb size (64bit system), okteta crashes with: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc KCrash: Application 'okteta' crashing... sock_file=/home/benjamin/.kde4/socket-metis/kdeinit4__0 okteta: Fatal IO error: client killed I interpret this as okteta trying to allocate memory for the entire file. But this is not needed! Just load the parts you need for display (+some) and load ondemand when needing other parts, freeing when parts are not used anymore. There are other hexeditors out there which do this correctly. It would be great if okteta would too Thanks
Thanks for your report. This is a known problem (see http://utils.kde.org/projects/okteta/faq.php) from the start, but the support in the code is not yet completed. Please be patient :) Some future version will hopefully finally be capeable, no promises which it will be.
When Okteta has large file support, please let it work on block devices, too. I tried it on a block dev, and it thinks the file has zero length. Obviously that's a better failure mode than trying to load the whole block dev into RAM. BTW, someone was working on large file/in-place editting support for ghex, and maybe designing a class that would work like a regular document, but load regions from the large file on the fly, as needed. That probably never got anywhere, though. There was some discussion about how a hex editor should work (overwrite in place vs. save to new file), and stuff... you may want to read https://bugzilla.gnome.org/show_bug.cgi?id=91494 Although Okteta already seems to rewrite in-place, it does truncate the file in the process (O_WRONLY|O_CREAT|O_TRUNC), which is not what I'd expect a hex editor in overwrite mode to do. Not sure how this might interact with another process which had e.g. a disk image file memory mapped.
Doesn't crash in the latest version, while still unable to load large files, so downgrading from "crash" to "normal". Hopefully one day I finally get to fix this...
*** Bug 253027 has been marked as a duplicate of this bug. ***
*** Bug 277553 has been marked as a duplicate of this bug. ***
*** Bug 311115 has been marked as a duplicate of this bug. ***
I think that a quick workaround could be to be able to open a portion of a file.
(In reply to comment #1) > http://utils.kde.org/projects/okteta/faq.php Link doesn't work. Maybe http://userbase.kde.org/Okteta is better?
Any good alternatives since this is still not fixed?
Hi Soukyuu. You could have a look at http://www.wxhexeditor.org/. Not tried myself, but it was done especially for the purpose to also read large files and complete filesystems.
*** Bug 458712 has been marked as a duplicate of this bug. ***
Ping. It has been over a dozen years and nobody has figured out how to load a screen-full at a time from a file opened in random-access mode? There is a KDE-compatible development package called Qt6 with functions such as QFileDevice which grabs, piece of data that fits into a buffer where you can use a model to display pages widget or dialog: uchar *QFileDevice::map(), along with 64-bit fun stuff like seek(), pos(), readData() and writeData(). Is it that unreasonable to assume someone with write permission on Okteta can get smart enough on these tools to implement terabyte-sized file I/O which did not exist in C++14 a decade ago? https://doc.qt.io/qt-6/qfiledevice.html