ghex truncates large files when saving

[Peter Cordes]

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!

[Gianni Tedesco (raunchpad)]

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

[Peter Cordes (peter-cordes)]

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

[André Klitzing (misery)]

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

[Mikael Magnusson (mikma)]

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