<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-08-25 14:19 GMT+03:00 Pino Toscano <span dir="ltr"><<a href="mailto:ptoscano@redhat.com" target="_blank">ptoscano@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Wednesday, 24 August 2016 23:59:54 CEST Matteo Cafasso wrote:<br>
> The internal_find_inode command searches all entries referring to the<br>
> given inode and returns a tsk_dirent structure for each of them.<br>
><br>
> The command is able to retrieve information regarding deleted<br>
> or unaccessible files where other commands such as stat or find<br>
> would fail.<br>
><br>
> The gathered list of tsk_dirent structs is serialised into XDR format<br>
> and written to a file by the appliance.<br>
><br>
> Signed-off-by: Matteo Cafasso <<a href="mailto:noxdafox@gmail.com">noxdafox@gmail.com</a>><br>
> ---<br>
> daemon/tsk.c | 75 ++++++++++++++++++++++++++++++<wbr>++++++++++++++++++++++<br>
> generator/<a href="http://actions.ml" rel="noreferrer" target="_blank">actions.ml</a> | 9 +++++++<br>
> src/MAX_PROC_NR | 2 +-<br>
> 3 files changed, 85 insertions(+), 1 deletion(-)<br>
><br>
> diff --git a/daemon/tsk.c b/daemon/tsk.c<br>
> index dd368d7..beb92a3 100644<br>
> --- a/daemon/tsk.c<br>
> +++ b/daemon/tsk.c<br>
> @@ -44,6 +44,7 @@ enum tsk_dirent_flags {<br>
><br>
> static int open_filesystem (const char *, TSK_IMG_INFO **, TSK_FS_INFO **);<br>
> static TSK_WALK_RET_ENUM fswalk_callback (TSK_FS_FILE *, const char *, void *);<br>
> +static TSK_WALK_RET_ENUM ifind_callback (TSK_FS_FILE *, const char *, void *);<br>
> static char file_type (TSK_FS_FILE *);<br>
> static int file_flags (TSK_FS_FILE *fsfile);<br>
> static void file_metadata (TSK_FS_META *, guestfs_int_tsk_dirent *);<br>
> @@ -78,6 +79,35 @@ do_internal_filesystem_walk (const mountable_t *mountable)<br>
> return ret;<br>
> }<br>
><br>
> +int<br>
> +do_internal_find_inode (const mountable_t *mountable, int64_t inode)<br>
> +{<br>
> + int ret = -1;<br>
> + TSK_FS_INFO *fs = NULL;<br>
> + TSK_IMG_INFO *img = NULL; /* Used internally by tsk_fs_dir_walk */<br>
> + const int flags =<br>
> + TSK_FS_DIR_WALK_FLAG_ALLOC | TSK_FS_DIR_WALK_FLAG_UNALLOC |<br>
> + TSK_FS_DIR_WALK_FLAG_RECURSE | TSK_FS_DIR_WALK_FLAG_NOORPHAN;<br>
> +<br>
> + ret = open_filesystem (mountable->device, &img, &fs);<br>
> + if (ret < 0)<br>
> + return ret;<br>
> +<br>
> + reply (NULL, NULL); /* Reply message. */<br>
> +<br>
> + ret = tsk_fs_dir_walk (fs, fs->root_inum, flags, ifind_callback,<br>
> + (void *) &inode);<br>
<br>
</div></div>Here 'inode' is int64_t ...<br>
<div><div class="h5"><br>
> + if (ret == 0)<br>
> + ret = send_file_end (0); /* File transfer end. */<br>
> + else<br>
> + send_file_end (1); /* Cancel file transfer. */<br>
> +<br>
> + fs->close (fs);<br>
> + img->close (img);<br>
> +<br>
> + return ret;<br>
> +}<br>
> +<br>
> /* Inspect the device and initialises the img and fs structures.<br>
> * Return 0 on success, -1 on error.<br>
> */<br>
> @@ -141,6 +171,51 @@ fswalk_callback (TSK_FS_FILE *fsfile, const char *path, void *data)<br>
> return ret;<br>
> }<br>
><br>
> +/* Find inode callback, it gets called on every FS node.<br>
> + * Parse the node, encode it into an XDR structure and send it to the appliance.<br>
> + * Return TSK_WALK_CONT on success, TSK_WALK_ERROR on error.<br>
> + */<br>
> +static TSK_WALK_RET_ENUM<br>
> +ifind_callback (TSK_FS_FILE *fsfile, const char *path, void *data)<br>
> +{<br>
> + int ret = 0;<br>
> + CLEANUP_FREE char *fname = NULL;<br>
> + uint64_t *inode = (uint64_t *) data;<br>
<br>
</div></div>... but then here you cast it as uint64_t. I don't see an immediate<br>
issue with it, but please keep in mind that this kind of things in C<br>
(i.e. cast a typed pointer to void*, and cast it back as some other<br>
type) is dangerous, and should be avoided as much as possible.<br></blockquote><div>I do agree with your point. Reason behind the cast is that the comparison few lines below is done against a uint64_t.<br><br></div><div>Moreover, other related APIs parameters are int64_t (download_inode and download_blocks). This would make the APIs inconsistent between each other.<br><br></div><div>If I picture myself as a user I would wonder why download_inode() wants a int64_t and find_inode() wants a uint64_t.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I guess the proper solution would be adding a new UInt64 type (and UInt<br>
as well) to the generator...<br></blockquote><div>I am not familiar with the generator architecture. What would adding a type to it imply from the practical point of view?<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
<span class=""><font color="#888888">--<br>
Pino Toscano</font></span><br>______________________________<wbr>_________________<br>
Libguestfs mailing list<br>
<a href="mailto:Libguestfs@redhat.com">Libguestfs@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/libguestfs" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/libguestfs</a><br></blockquote></div><br></div></div>