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