Re: [sleuthkit-users] Multiple questions

[Joachim M. <joa...@gm...>]

Brian thanks for accepting the patches.


On Fri, Aug 30, 2013 at 7:22 AM, Joachim Metz <joa...@gm...>wrote:

> I've also added a fix for a memory leak in the yaffs code for the error
> code path. I'm wondering though if a particular member of the yaffs
> internal structure chunkMap is freed in the normal code path?
> I've not tested it yet with a yaffs test image, but if you do please run a
> tool like valgrind on the tsk tools i.c.w. the yaffs test image.
>
>
> On Thu, Aug 29, 2013 at 7:23 AM, Joachim Metz <joa...@gm...>wrote:
>
>> > I haven't tracked the final number. Is that set by the libtool/LDFLAGS
>> version?
>>
>> This is controlled by:
>> libtsk_la_LDFLAGS = -version-info 10:0:0
>>
>> in: tsk/Makefile.am
>>
>> > It looks good.  I'll review it later today and merge it in.
>> Thanks, but please revisit the code in this file I did not touch.
>>
>> Also seeing the compiler warnings I expect there are signed/unsigned
>> issues in various more places.
>>
>> > I see Jeff every day at work.  We're waiting to merge that in, but
>> will probably do it by end of week. In hindsight, we should probably have
>> made a 64-bit branch instead.
>>
>> Can you maybe add something to the develop guidelines about what to
>> expect and which email address to ping for more urgent patches?
>>
>> http://wiki.sleuthkit.org/index.php?title=Developer_Guidelines
>>
>>
>>
>>
>>
>> On Thu, Aug 29, 2013 at 5:07 AM, Brian Carrier <ca...@sl...>wrote:
>>
>>> Hey Joachim,
>>>
>>> On Aug 28, 2013, at 4:57 PM, Joachim Metz wrote:
>>>
>>> > So I've just add a pull request to github, can anyone tell me what to
>>> expect on the response side?
>>>
>>> It looks good.  I'll review it later today and merge it in.
>>>
>>> > I see one other recent pull request of 14 days ago where it seems no
>>> one from the project has replied.
>>>
>>> I see Jeff every day at work.  We're waiting to merge that in, but will
>>> probably do it by end of week. In hindsight, we should probably have made a
>>> 64-bit branch instead.
>>>
>>> > Note that this pull request is supposed to fix a serious defect
>>> causing the current code to segfault. Also at first glance this file needs
>>> some serious revisiting.
>>> >
>>> >
>>> > Also what's up with the current so version number, why did it jump
>>> from 3 to 9 to 10 !? Also because the API is largely untouched?
>>> >
>>> > sleuthkit 3.x.x was soname libtsk3.3
>>> > sleuthkit 4.0.0 was soname libtsk3.3
>>> > sleuthkit 4.0.1 was soname libtsk3.9
>>> > sleuthkit 4.0.2 was soname libtsk3.9
>>> > sleuthkit 4.1.0 was soname libtsk.10
>>>
>>> I haven't tracked the final number. Is that set by the libtool/LDFLAGS
>>> version?
>>>
>>> > Also can someone elaborate on the sudden change of hart to rename
>>> libtsk3 into libtsk?
>>>
>>> Because TSK has been version 4 for almost a year and the '3' was for
>>> version 3. I dropped the version from the library name (and include paths).
>>>
>>> brian
>>>
>>>
>>>
>>
>