Re: [Qemu-devel] [PULL 2/4] usb-mtp: fix some usb_mtp_write_data return paths

[Peter Maydell]

On Fri, 15 Mar 2019 at 15:49, Bandan Das <address@hidden> wrote:
> usb_mtp_write_metadata() handles the sendobjectinfo phase where the
> initiator sends the metadata associated with the incoming object.
> For a file, the name and the size is sent and once the responder sends
> back OK, the initiator starts the sendobject phase. For a folder,
> the name of the folder is sent with size being 0, and
> no sendobject phase follows.

Thanks for the explanation.

> So, the reason I am sending back the return
> value is because for a folder, I want to send a success or a failure
> based on whether mkdir succeeded but for a file object, I want to return
> success so that the next phase can continue. Is this rewrite better ?
>
>  static void usb_mtp_object_delete(MTPState *s, uint32_t handle,
> @@ -1674,7 +1666,13 @@ static void usb_mtp_write_data(MTPState *s)
>          if (s->dataset.filename) {
>              path = g_strdup_printf("%s/%s", parent->path, 
> s->dataset.filename);
>              if (s->dataset.format == FMT_ASSOCIATION) {
> -                d->fd = mkdir(path, mask);
> +                if (mkdir(path, mask)) {
> +                    usb_mtp_queue_result(s, RES_STORE_FULL, d->trans,
> +                                         0, 0, 0, 0);
> +                } else {
> +                    usb_mtp_queue_result(s, RES_STORE_FULL, d->trans,
> +                                         0, 0, 0, 0);
> +                }

Presumably one of these should be RES_OK of some kind ?

>                  goto free;
>              }

It does seem like a more consistent approach if we can say
"usb_mtp_write_data() will always queue an appropriate result"
rather than having it do that for some use cases and not others,
so I like this suggestion.

thanks
-- PMM