Skip to content

mtp: Don't retry reading an event after failure

Philip Langdale requested to merge philipl/gvfs:master into master

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: #347 (closed)

Merge request reports