similar to: [PATCH] hivex: python: value_value no longer generates Unicode strings

--- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 6785037..203f34f 100644 --- a/configure.ac +++ b/configure.ac @@ -329,8 +329,8 @@ AS_IF([test "x$enable_python" != "xno"], AC_MSG_CHECKING([for Python extension suffix (PEP-3149)]) if test -z "$PYTHON_EXT_SUFFIX"; then

Since values are now returned as strings in Python2 and Python3, treating them as bytes in Python 3 would break tests. --- python/t/210-setvalue.py | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/python/t/210-setvalue.py b/python/t/210-setvalue.py index 9d93519..2ee7ac5 100644 --- a/python/t/210-setvalue.py +++ b/python/t/210-setvalue.py @@ -47,20 +47,12 @@

Hi, This patch series is based on a prior patch[1], splitting off changes as requested and incorporating feedback from Richard Jones. It introduces type validation to avoid segmentation faults (instead, it reports an exception) and fixes handling of the bytes type in Python 3. Major changes since that series: - Drop newly introduced support for integer types for DWORD/QWORDS - Reject Unicode

Use better functions to check for proper values instead of assert: - refute_nil for non-null functions - assert_equal for checking equality Also, make sure that the parameters for assert_equal are correct: expected value, then got value. --- ruby/tests/tc_120_rlenvalue.rb | 4 ++-- ruby/tests/tc_130_special.rb | 12 ++++++------ ruby/tests/tc_200_write.rb | 4 ++--

Hallo, I working on GUI interface for users to manipulate Windows Registry. For that I choose to use really excellent library hivex3. Just now I'm performing same test to see, if everything is saved correctly. Most of things work really well, but there is problem with saving some values and his types. Description of problem: For saving values is used function : node_set_values or

Hi, I have been working on a Python application that uses hivex. Meanwhile I have encountered some Python bindings issues which could be fixed. The next issue I see now is about the value_value function. This is briefly documented as: "return data length, data type and data of a value". For Perl, Python and OCaml, this is not true. A tuple is returned for both without the length

(renaming subject as I am partially getting off-topic) On Sunday 10 August 2014 16:26:07 Richard W.M. Jones wrote: > > The next issue I see now is about the value_value function. This is > > briefly documented as: "return data length, data type and data of a > > value". > > > > For Perl, Python and OCaml, this is not true. A tuple is returned > >

Round 3 -- this time with working OCaml bindings. (I'm not on the list, please copy me on replies, thanks.) --- generator/generator.ml | 77 ++++++++++++++++++++++++++++++++++++++++- lib/hivex.c | 90 ++++++++++++++++++++++++++++++++++++++++++++++++ perl/t/201-setvalue.t | 54 ++++++++++++++++++++++++++++ 3 files changed, 219 insertions(+), 2 deletions(-) create mode 100644

Added Perl binding glue and a simple test along the lines of present tests. (And again: I'm not on the list, please CC me on replies. Thanks!) --- generator/generator.ml | 62 +++++++++++++++++++++++++++++++-- lib/hivex.c | 90 ++++++++++++++++++++++++++++++++++++++++++++++++ perl/t/201-setvalue.t | 54 ++++++++++++++++++++++++++++ 3 files changed, 203 insertions(+), 3

Before this patch, Python would segfault once you pass a non-string key or value to node_set_value. It was also not possible to set bytes on Python 3 as Unicode was assumed (Python 2 was not affected by this). This patch fixes recognition of bytes for Python 3, but in addition it recognizes ints (includes 'long' in Python 2) for DWORD (LE + BE) and QWORDs. For this purpose, a new field

Hi Rich, While I was looking at hivex today I ran coverity on it. It spotted one problem but missed a similar one nearby. The following are from Hivex.xs: (generated by generator.ml) void node_set_values (h, node, values) hive_h *h; int node; pl_set_values values = unpack_pl_set_values (ST(2)); PREINIT: int r; PPCODE: r = hivex_node_set_values (h, node,

Signed-off-by: Alex Nelson <ajnelson at cs.ucsc.edu> --- images/mkrlenvalue_test_hive.py | 37 +++++++++++++++++++++++++++++++++++++ images/rlenvalue_test_hive | Bin 0 -> 12288 bytes 2 files changed, 37 insertions(+), 0 deletions(-) create mode 100755 images/mkrlenvalue_test_hive.py create mode 100644 images/rlenvalue_test_hive diff --git a/images/mkrlenvalue_test_hive.py

Hello, thanks for answer, it works pretty good. I'm still little bit confused about saving binary values. I understand that there can be risk, to write wrong sequence of bites to hive but in regular MS Regedit this posibility is and when someone really know what he does, it should be able to change bites directly. So how achieve that with hivex? I noticed that hivex return binary data

On a Debian/unstable chroot environment on smetana.debian.org ("Linux smetana 2.6.32-5-sparc64-smp #1 SMP Tue Mar 8 01:00:11 UTC 2011 sparc64 GNU/Linux") node_set_value and node_values fail with a "Bad address" error, see below. I am going to make an attempt at debugging this tonight, any advice would be appreciated. Cheers, -Hilko ,---- | (sid)bengen at

Hi, When an integer argument is passed as value, node_set_value segfaults. Reproducer is at the end of this message The backtrace points at hivex-py.c, function get_value. While obj is non-NULL, `bytes = PyUnicode_AsUTF8String (obj);` returns NULL. Kind regards, Peter https://lekensteyn.nl #!/usr/bin/env python3 import hivex, sys h = hivex.Hivex(sys.argv[1]) print(h) val = {

If a Windows boot fails and the user boots the last known good configuration, ControlSet001 will be marked as failed and no longer used. However, virt-v2v would only install viostor to ControlSet001, meaning it will fail to boot this guest after conversion. This patch looks up the current controlset and always installs registry keys to the correct one. Fixes RHBZ#644254 ---

Currently when converting a Windows guest we do a minimum installation of the viostor driver, configure the RHEV guest agent and leave RHEV to properly install viostor and all remaining drivers. This works well if RHEV is properly configured and the installation is not interrupted on first boot. However, if the target of the conversion is not RHEV, RHEV is not properly configured, or the first

I won't pretend I really understand what's going on here. I've CC'd this message to Chris since he might have a better idea. https://bugzilla.redhat.com/show_bug.cgi?id=733297 In this bug, it appears that the event log callback goes out of scope and is garbage collected. (This is despite the fact we registered it as a global root). When we invoke the callback later,

[third sending attempt...] I''m going to try and test out the samples on MSW over the next few days and if things look good I think we should release 1.9.2. Might try and fix the bugs related to TreeCtrl#get_first_child as these might involve minor API changes. So if anyone has any time to test out SVN HEAD and look for anything funny, please do. Also, we have an anonymous patch

Signed-off-by: Alex Nelson <ajnelson at cs.ucsc.edu> --- ruby/tests/tc_120_rlenvalue.rb | 46 ++++++++++++++++++++++++++++++++++++++++ 1 files changed, 46 insertions(+), 0 deletions(-) create mode 100644 ruby/tests/tc_120_rlenvalue.rb diff --git a/ruby/tests/tc_120_rlenvalue.rb b/ruby/tests/tc_120_rlenvalue.rb new file mode 100644 index 0000000..ff920af --- /dev/null +++