In the case where a file cannot be opened for reading, we were not emitting a 'finished' signal to communicate the error to the client. I was intending to further fix this issue by 'rejecting' the drop (in SpiceDisplay) when the URI list contains invalid files (e.g. directories). This would prevent a 'new-file-transfer' signal from even being emitted for these invalid files. But this turns out to be not very useful since there's no real feedback given to the user to indicate why the drop failed. So it's probably better for client applications to get the 'new-file-transfer' and 'finished' signals so that they can present the error to the user to explain why the attempted transfer did not work. --- Changes since v1: - include additional explanation in commit log as suggested by Fabiano on IRC src/channel-main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/channel-main.c b/src/channel-main.c index ffeb0ba..3a8c1dd 100644 --- a/src/channel-main.c +++ b/src/channel-main.c @@ -2935,7 +2935,7 @@ static void spice_file_transfer_task_completed(SpiceFileTransferTask *self, if (!self->priv->file_stream) { file_xfer_close_cb(NULL, NULL, self); - return; + goto signal; } g_input_stream_close_async(G_INPUT_STREAM(self->priv->file_stream), @@ -2944,6 +2944,7 @@ static void spice_file_transfer_task_completed(SpiceFileTransferTask *self, file_xfer_close_cb, self); self->priv->pending = TRUE; +signal: g_signal_emit(self, task_signals[SIGNAL_FINISHED], 0, error); } -- 2.4.3 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel