| Summary: | Okteta unable to load large files | ||
|---|---|---|---|
| Product: | [Applications] okteta | Reporter: | Benjamin Schindler <beschindler> |
| Component: | general | Assignee: | Friedrich W. H. Kossebau <kossebau> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | ale, benpro82, chrno-sphered, Daniel, hpfeil, hpj, kdebugs, peter, starguysoft |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Benjamin Schindler
2009-01-31 13:57:43 UTC
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 |