ghex truncates large files when saving
Bug #165213 reported by
Peter Cordes
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ghex |
In Progress
|
Medium
|
|||
ghex (Ubuntu) |
Confirmed
|
Medium
|
Unassigned |
Bug Description
Binary package hint: ghex
I was using ghex2 to look at the beginning of an 8.6GB .wav file. I changed a byte and saved the file, and now it's only 612MB. (I think it's no coincidence that ghex2 is using just a bit more RAM than that: RSS=626MB).
I really like ghex2's UI, with interpretations of the next 1, 2 and 4 bytes as signed or unsigned integer, which is why I put up with it's memory wastage. Hex editors are not supposed to rewrite the whole file. They're supposed to edit in place. And mmap() the file if you want, but don't load it all into RAM!
Changed in ghex: | |
status: | Unknown → In Progress |
Changed in ghex: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Changed in ghex: | |
importance: | Unknown → Medium |
To post a comment you must log in.
I also noticed problems with ghex and large files. Is it a 32 or 64 bit CPU that you're using? I'm not sure ghex is designed to handle that big a file at all. Besides it ought to save to a temporary file and rename it over the original, just to be safe and avoid chomping your data anyway.
As for the performance with big files, mmap is the way to go. The attached patch demonstrates this. I tried it out on some fairly modestly sized files (600MB sort of ballpark) and the results were predictably spectacular. This patch is a bug-ridden hack but it might work for your case.
I started work on doing all this portably with glib. There's a way to do it without changing the UI behaviour but it's not a trivial one-nighter and my school homework + other things got in the way for now so...