On 05/04/16 19:33, Pino Toscano wrote:
On Tuesday 05 April 2016 18:47:28 Matteo Cafasso wrote:
The tsk_dirent struct contains the information gathered via TSK APIs.

The struct contains the following fields:
 * tsk_inode: inode of a file
 * tsk_type: type of file such as for dirwalk command
 * tsk_size: file size in bytes
 * tsk_name: path relative to its disk partition
 * tsk_allocated: whether the file has been deleted

Signed-off-by: Matteo Cafasso <noxdafox@gmail.com>
---
 generator/structs.ml | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/generator/structs.ml b/generator/structs.ml
index 6017ba6..d986fd9 100644
--- a/generator/structs.ml
+++ b/generator/structs.ml
@@ -442,8 +442,20 @@ let structs = [
     "im_device", FString;
     "im_volume", FString;
     ];
-    s_camel_name = "InternalMountable";
-  };
+    s_camel_name = "InternalMountable" };
Unneeded change.

+  (* The Sleuth Kit directory entry information. *)
+  { defaults with
+    s_name = "tsk_dirent";
+    s_cols = [
+    "tsk_inode", FUInt64;
+    "tsk_type", FChar;
+    "tsk_size", FInt64;
+    "tsk_name", FString;
+    "tsk_allocated", FUInt32;
Once added to the public API, a struct cannot be extended anymore
(it would break the ABI).  IMHO it would make more sense to have
a tsk_flags instead of tsk_allocated, documenting the values of the
flags/bits set: this way, adding a new simple boolean flag won't
require a new tsk_dirent2 (see e.g. the application2 struct).

The application2 structs shows pretty well the issue but does not have any bitwise flag.
Is there an example I could use as a reference? Especially I'd like to see how flags are exposed and documented.


Thanks,


_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs