[Libguestfs] [PATCH v3 1/3] New API: internal_find_block

[NoxDaFox]

2016-09-23 11:52 GMT+03:00 Pino Toscano <ptoscano at redhat.com>:

> On Tuesday, 20 September 2016 16:19:30 CEST Matteo Cafasso wrote:
> > +  for (index = 0; index < count; index++) {
> > +    fsattr = tsk_fs_file_attr_get_idx (fsfile, index);
> > +
> > +    if (fsattr != NULL && fsattr->flags & TSK_FS_ATTR_NONRES)
> > +      tsk_fs_attr_walk (fsattr, flags, attrwalk_callback, (void *)
> &blkdata);
>
> The return code of tsk_fs_attr_walk must be checked.
>

I'll fix.


>
> > +/* Attribute walk, searches the given block within the FS node
> attributes.
> > + *
> > + * Return TSK_WALK_CONT on success, TSK_WALK_ERROR on error.
> > + */
> > +static TSK_WALK_RET_ENUM
> > +attrwalk_callback (TSK_FS_FILE *fsfile, TSK_OFF_T offset,
> > +                   TSK_DADDR_T blkaddr, char *buf, size_t size,
> > +                   TSK_FS_BLOCK_FLAG_ENUM flags, void *data)
> > +{
> > +  findblk_data *blkdata = (findblk_data *) data;
> > +
> > +  if (!(flags & TSK_FS_BLOCK_FLAG_SPARSE) && blkaddr == blkdata->block)
> {
> > +    blkdata->found = true;
>
> If we want to ignore sparse blocks, wouldn't it make sense to pass
> TSK_FS_FILE_WALK_FLAG_NOSPARSE as additional flag to tsk_fs_attr_walk
> above?
>
> Also, my concerns about this that I replied in v2 still stand: is the
> documentation obsolete, or does it document what is the expected
> behaviour? In the former case, then it could be ok to partially
> disregard what it said; in the latter, the code should follow what
> it describes.
>
> In any case, you should get in touch with the sleuthkit developers,
> and get their feedback about that.
>

Right, I'll write something on their devs list.


>
> --
> Pino Toscano
> _______________________________________________
> Libguestfs mailing list
> Libguestfs at redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20160923/2b6b4f12/attachment.htm>