Hi Richard
I've added a new patch. See some in-line comments. That said, I made a
couple of more changes to my patch, re-using the free_blocks for doing
all allocations (i.e. not using h->endblocks at all).
On 2018-07-25 07:32 AM, Richard W.M. Jones wrote:
On Mon, Jul 23, 2018 at 02:38:18PM -0400, Shreyas Khare wrote:
> Hello Richard
>
> As discussed in the IRC channel, when merging a moderately large reg
> file (~35MB) to a hiv file (~118 MB); hivex generates a huge hiv
> file (~580 MB). These changes address that by creating a list of
> unallocated blocks and reassigning unused blocks. I used
https://github.com/msuhanov/regf/blob/master/Windows%20registry%20file%20...
> as a reference for the structure of the hiv file (in addition to the
> source code itself)
>
> Attaching the patch file.
Just as a general comment, for the patch to go upstream at all it will
need to be reformatted so it fits with the existing code style.
[...]
Will do.
> /* Allocate a single block, first allocating an hbin (page) at
the end
> * of the current file if necessary. NB. To keep the implementation
> * simple and more likely to be correct, we do not reuse existing free
This comment is left in place, but it's now obviously wrong.
Fixed.
I'm a bit confused why we need a separate free list. Can't
we just
use the existing bitmap?
I tried to use the existing bitmap, but wasn't
successful initially with
the 20 byte hbin headers on every page.
Rich.
--
NOTICE OF CONFIDENTIALITY: At Rapid7, the privacy of our customers,
partners, and employees is paramount. If you received this email in error,
please notify the sender and delete it from your inbox right away. Learn
how Rapid7 handles privacy
at rapid7.com/privacy-policy
<
https://www.rapid7.com/privacy-policy/>. To opt-out of Rapid7 marketing
emails, please click here
<
https://information.rapid7.com/manage-subscription.html> or email
privacy(a)rapid7.com <mailto:mailto:privacy@rapid7.com>.