ghex truncates large files when saving

Bug #165213 reported by Peter Cordes
12
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!

Revision history for this message
Gianni Tedesco (raunchpad) wrote :

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...

Revision history for this message
Peter Cordes (peter-cordes) wrote : Re: [Bug 165213] Re: ghex truncates large files when saving

On Fri, Jan 04, 2008 at 01:08:10AM -0000, Gianni Tedesco wrote:
> I also noticed problems with ghex and large files. Is it a 32 or 64 bit
> CPU that you're using?

 64bit: AMD64 Ubuntu Gutsy.

> 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.

 Yeah, as long as it always re-writes the whole file anyway, that's a good
plan. It's not really useable on block devices of any significant size
anyway, with its current design.

> 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...

 I don't really have time to spend on this either. :(

--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

Revision history for this message
André Klitzing (misery) wrote :

Found that old bug report in gnome's bugzilla. Maybe that is "your" problem, too?

Changed in ghex:
status: Unknown → In Progress
Daniel T Chen (crimsun)
Changed in ghex:
importance: Undecided → Medium
status: New → Confirmed
Changed in ghex:
importance: Unknown → Medium
Revision history for this message
Mikael Magnusson (mikma) wrote :

SInce this bug is still open, are there an alternative hex file viewer for gnome in Ubuntu which supports large files using mmap?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.