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 <noxda...@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
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
