On Fri, 15 Mar 2019 at 15:49, Bandan Das <b...@redhat.com> 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