| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
We've supported these old versions for many years now. We're overdue
pruning the list back.
https://bugzilla.gnome.org/show_bug.cgi?id=795312
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Android P has introduced support for these operations, and they
are useful - making device->device moves and copies much faster
and less vulnerable to messy failures.
After making the relevant changes in libmtp, I've now added
implementations here. The basic mechanics are simple, but we
need to include the precise handling of file vs directory
combinations that were first put together for the push operation.
The one main difference is that moves and copies of folders work
correctly, and these do not need to be decomposed.
Note that these operations provide no progress information (the
MTP spec does not provide for it), but they can take a long time,
especially for copies. This results in the client (eg: Nautilus)
spinning without progress reporting. Unfortunately, there's nothing
we can do; at least the operation is faster.
https://bugzilla.gnome.org/show_bug.cgi?id=794388
|
| |
|
|
|
|
| |
HAVE_GUDEV guards are redundant, because gudev is hard requirement.
https://bugzilla.gnome.org/show_bug.cgi?id=786149
|
| |
|
|
|
|
|
|
|
| |
Uevent handler with "remove" action may be called multiple times,
which causes that g_vfs_backend_force_unmount is called several
times, which may lead to segfault. Disconnect the uevent handler
immediately after g_vfs_backend_force_unmount call.
https://bugzilla.gnome.org/show_bug.cgi?id=777794
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Welcome to the end of this little road.
With all the refactoring in place, we are now in a position to
introduce the use of LIBMTP_Read_Event_Async. This version of
Read_Event uses an explicit asynchronous API, which gives us more
control over how long it blocks in a polling call, and what happens
if it is interrupted.
According to libusb documentation, a blocking poll will be interrupted
when the device being polled is closed. This means we should be
able to block indefinitely, and close the device during our
unmount and have the poll call return so our thread can terminate
cleanly.
In theory, this approach should work with the original poll
mechanism using the synchronous API, but that seems risky based
on the crashes we've seen. When the synchronous API is interrupted,
it returns to code (in libusb) that doesn't actually stop polling;
it will attempt to start the poll operation again. This leads to
a segfault as the device state is gone.
By using the explicit asynchronous API, we are able to ensure
that only safe code is called after the interruption.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=761278
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the next, and hopefully final, change in this series, I'm going
to introduce a new way of checking for events that avoids the race
condition which can lead to crashes on unmount in the current code.
As part of that, event handling must move off the checking thread
to a separate thread. But even the existing checking mechanism
could stand to benefit from using a separate thread.
It's generally undesirable for a thread that's polling for activity
to potentially block for a long time, and this is what could happen
today if there's a long transfer happening when an event comes in.
With the separate handler thread, we can dispatch the work and then
resume polling for activity quickly.
I used a single-thread thread pool to handle the heavy lifting of
queuing events - there's no benefit to writing that yourself.
Finally, some thoughts on synchronization:
1) The thread pool has the lifetime of the backend. It is important
not to tie it to mount state, as this would lead to requiring holding
the backend mutex to know it is safe to push an event to the pool,
and that brings us back to potentially blocking the checking thread
again.
2) While the thread pool needs the extended lifetime, we don't want
to handle events once unmount has started. We enforce this in two
ways.
a) We set the pool thread count to 0 in unmount. From here on,
newly queued events will not get dispatched.
b) We reorder the checks in handle_event() so that it always attempts
to take the backend mutex first. After taking the mutex, it will
check if an unmount is underway. This ensures that either an unmount
has not started and it is safe to handle the event, or the unmount
is complete, and we know we should drop the event.
|
| |
|
|
|
|
|
|
| |
Read support is allowed currently only if android.com extension is
detected. However necessary functions can be provided also by different
extension. Therefor check whether GetPartialObject is supported.
https://bugzilla.gnome.org/show_bug.cgi?id=743359
|
| |
|
|
|
|
|
| |
Leak the mutex if the backend is force unmounted to avoid crash
caused by abort(), when trying to clear already locked mutex.
https://bugzilla.gnome.org/show_bug.cgi?id=739575
|
| |
|
|
|
|
|
|
|
|
| |
If the device has no friendly name, set the display name of the device
from the udev info to match the name shown by the volume monitor.
This is visible as the folder title when the root dir of the device is
open in Nautilus (or using gvfs-info).
https://bugzilla.gnome.org/show_bug.cgi?id=736285
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=721510
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's becoming too fragile to use item IDs as path elements. Beyond
the problems with clients that don't use copy names, there are a
bunch of situtations where a path sent by a client could be an id
or a filename and it's not 100% possible to tell them apart.
When the initial feature set of very limited, this wasn't much
of an issue, but with direct read/write support, we are now
exposed to a huge set of clients (as opposed to just file managers)
with no ability to recognise copy names, and which generate a lot
of mixed form paths, so we're past the tipping point where it's now
less of a hassle to maintain a name to id mapping.
https://bugzilla.gnome.org/show_bug.cgi?id=696016
|
| |
|
|
|
|
| |
Allows for opening files directly on the device and reading from them.
https://bugzilla.gnome.org/show_bug.cgi?id=695984
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've never seen this happen personally, but an Ubuntu bug reported
that on_uevent fired after the gudev client had been finalized, so
it must be possible to race between an explicit unmount and
physically unplugging a device. I made a brief attempt to reproduce
this but couldn't.
In any case, it's easy enough to protect against by taking a few
measures:
1) Explicitly disconnect the signal handler before unref'ing the
gudev client.
2) Use g_signal_connect_object to keep the backend alive enough
for on_uevent to complete.
3) NULL out the dev_path so that if we end up in on_uevent after
do_unmount has cleared the dev_path, the compare will fail
gracefully.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Theoretically, the event check could fire during unmount, resulting
in access to invalid backend state. We can try and minimise the
chance of this happening but can't elimiate it completely as the
LIBMTP_Read_Event call cannot occur with a lock or ref held as it
blocks and cannot be interrupted as part of the shutdown process.
If a lock was held, it would lead to a deadlock, and if a ref was
held, the backend would never finalize.
As it is, the race is now narrowed so that it's only applicable if
the unmount occurs at the point between where the MTP device is
looked up and when Read_Event is called.
And even before this change the race was incredibly rare as you'd
have to induce an MTP event in the middle of unmounting.
Finally, crashing while trying to terminate isn't the end of the
world.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
With the volume monitor in place, the backend is now one per device,
so we can throw out all the device enumeration and tracking logic.
|
| |
|
|
| |
Will be used to detect device plug/unplug events.
|
| | |
|
|
|
Currently just does basic entity enumeration, but supports multiple
devices and storages.
Does not support download and upload yet.
|
