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