[gvfs] mtp: Don't retry reading an event after failure

[Philip Langdale <philipl src gnome org>]

commit 63700b556522cb779fee9b7f45b869df6b178c68
Author: Philip Langdale <philipl overt org>
Date:   Thu Dec 20 10:33:41 2018 -0800

    mtp: Don't retry reading an event after failure
    
    This issue has been sitting around for ages without us understanding
    what's going on. We finally got a repro scenario which showed that
    it happens when another program steals the MTP device out from under
    us, so that all MTP calls will start failing. In this case it's clear
    that it's futile to keep trying to retry reading the event after a
    failure.
    
    I originally wrote the code to retry the read because I expected any
    error to be transitory, but if the error is persistent, it's not good
    behaviour - even if the memory leak was fixed (as you'd still be
    busy-waiting in a tight loop).
    
    So, given the situation, and the fact that I'm not aware of any
    occurence of transitory event read failures, let's just say that
    if an event read fails, we'll give up and the event is lost.
    
    Note that I'm still not aware of the exact situation where the
    problem was first observed (the reporters did not talk about
    the use of VM software stealing devices) and so fixing this may
    still result in them seeing a situation where they can't access
    the device due to whatever the underlying cause is.
    
    Closes: https://gitlab.gnome.org/GNOME/gvfs/issues/347

 daemon/gvfsbackendmtp.c | 1 -
 1 file changed, 1 deletion(-)
---
diff --git a/daemon/gvfsbackendmtp.c b/daemon/gvfsbackendmtp.c
index a7be4f3f..38a3ea95 100644
--- a/daemon/gvfsbackendmtp.c
+++ b/daemon/gvfsbackendmtp.c
@@ -652,7 +652,6 @@ check_event (gpointer user_data)
       ret = LIBMTP_Read_Event_Async (device, check_event_cb, backend);
       if (ret != 0) {
         g_debug ("(I) check_event: Read_Event_Async failed: %d\n", ret);
-        continue;
       }
       backend->event_completed = FALSE;
     }