On 07/03/16 21:31, Richard W.M. Jones wrote:
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
the idea to upstream but I guess they won't like it much.
Rich.