On Thu, Feb 04, 2010 at 01:34:10PM +0000, Matthew Booth wrote:
On 03/02/10 18:34, Richard W.M. Jones wrote:
Subject: [PATCH 08/12] hivex: Add HIVEX_OPEN_WRITE flag to allow hive to be opened for writing.
If this flag is omitted (as in the case for all existing callers) then the hive is still opened read-only.
We add a 'writable' flag to the hive handle, and we change the way that the hive file (data) is stored. The data is still mmapped if the file is opened read-only, since that is more efficient and allows us to handle larger hives. However if we need to write to the file then we have to read it all into memory, since if we had to extend the file we need to realloc that data.
Note the manpage section L</WRITING TO HIVE FILES> comes in a later commit.
I'm not convinced this is a good idea. It introduces an asymmetry which is like to lead to head-scratching bugs down the line.
Why can't we mremap where realloc would be necessary?
Actually I had no idea about mremap. It's a _GNU_SOURCE function so not portable ... But the reason we want a private copy with a separate 'commit' operation is because our write functions are not careful to clean up after themselves in the case where they fail (because doing that would introduce a huge, rarely tested set of error-path cases). So you need a separate commit operation which you only call when the previous write calls were all successful. At this point I'd prefer not to rewrite this code to use mremap, even though there would be some small saving in memory usage to have a private mapping. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora