Re: [Libguestfs] [PATCH 0/2] added icat and fls0 APIs for deleted files recovery
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'.
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).
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.
>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).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html