On Mon, Mar 07, 2016 at 08:14:41PM +0200, noxdafox wrote:
As the API documentation says, this is the low level API which I have provided as an example.
I took inspiration from the guestfs_ls0 API which does a similar job storing the content of a directory onto a host file.
If I understood correctly (the dynamic code generation is still confusing me a bit), the way Libguestfs implements commands which could have a large output is via first dumping it onto a local file and then iterating over it. This command would list the entire content of a disk including the deleted files therefore we need to expect a large output. Your understanding is correct. But the fls0 API still isn't safe because (I assume) it cannot handle filenames containing '\n'. I haven't considered this issue. This is why guestfs_ls0 separates the results using a '\0' character right? I'll try to reproduce this and see how TSK gives me the output.
There's another API which handles arbitrary length RStructList returns, which is: guestfs_lxattrlist / guestfs_internal_lxattrlist (see src/file.c:guestfs_impl_lxattrlist and daemon/xattr.c). I will take a look at these ones thanks!
What is missing is the higher level implementation which would pretty much look like the libguestfs_ls API. I need to better understand how to implement it and suggestions are more than appreciated. I tried to trace back how the guestfs_find is implemented for example, but I'm still a bit disoriented by the automagic code generation. See guestfs_impl_ls in src/file.c. All non_daemon_functions are implemented by some guestfs_impl_* function in the library side. I guess I'll come back with a complete solution with both low level and high level implementation.
Does TSK have a machine-readable mode? If it does, it'll definitely make things easier if (eg) JSON or XML output is available. If not, push upstream to add that to TSK -- it's a simple change for them, which will make their tools much more usable, a win for everyone. I personally disagree on this. The TSK `fls` command is a clone of the bash `ls` one. Maybe it's more similar to `ls -al` as it returns additional information. IMHO asking to upstream to add JSON or XML output format would sound pretty much as asking the same to bash for the `ls` utility.
The end result is to still return a list of structs or a list of strings. But parsing the `fls` output shouldn't be that hard. It's documentation is here: http://wiki.sleuthkit.org/index.php?title=Fls Well I still think it would be better to make this parsable. If I want to get information about a file in a shell script, I use the 'stat(1)' program since that has machine-readable output (stat -c). Indeed but in such case you know what to expect as the set of information is a closed and well defined one. In this case the options are unfortunately many. I can of course propose
On 07/03/16 21:31, Richard W.M. Jones wrote: the idea to upstream but I guess they won't like it much.
Rich.