On Linux systems, failure to watch a path may be caused by the limit set in
/proc/sys/fs/inotify/max_user_watches. This can be demonstrated by creating
a directory with a large number of empty subdirectories and adding that test
directory as a library.
Check that a file is readable before adding a watch. If adding the watch fails,
report the error to the user only once. Only add the path to subdir_mapping_
if watch succeeds.
QFileSystemWatcher::addPath returns a boolean to indicate success. Modify
QtFSListener::AddPath to reflect that. For now, the MacFSListener version will
always return true.
Using libmtp or libgphoto2 to access a device that gvfs has mounted causes the
connection to fail. libmtp is calling libusb_claim_interface which, according to
libusb documentation, will return LIBUSB_ERROR_BUSY if claimed by a different
program. For mtp and gphoto2 devices discovered by the GioLister, use the file
scheme and access the device through the gvfs mount.
The uri returned from g_file_get_uri is percent encoded. This causes the regex
in GioLister::MakeDeviceUrls to fail and causes the URL to be invalid. In this
case, it falls back to the file scheme. Newer versions of gvfs obtain the serial
id from udev instead of using the bus and device IDs.
Note that this bug covers a different issue where mtp is failing to connect. The
result is actually desired behavior. The follow-up change will address this.
A LibraryBackend may be deleted while an associated LibraryModel object is using
it. An example is an async query running while a connected device is removed.
To prevent this, use a share pointer for the LibraryBackend.
This fixes one case where LibraryBackend is used after deletion. However, the
raw pointer is still passed around in several other places. These should be
evaluated on a case-by-case basis to insure that circular depencencies aren't
introduced.
Create a thread pool for each LibraryModel object and block destruction until
all threads that are operating on this object are complete.
Note that this is not a complete solution. The async query also uses the library
backend which may still be deleted before the thread exits. This will be
addressed in a future change.
When a closure involves an ObjectHelper, a connection is made from the
receiver's destroyed signal and the helper object's deleteLater slot. Since
the signal between the sender and the helper object isn't disconnected until
either object is actually destroyed, this leaves a hole where the helper
holds a pointer to an invalid receiver object, but is still able to receive
the signal connected to its Invoke slot.
Instead of connecting the destroyed signal to deleteLater, connect it to a new
TearDown slot that immediately disconnects the signal then calls deleteLater.
A commit in qt 5.7 changes a qWarning to a qFatal if a QThread is still running
when it's deleted. When we get the LoadFinished signal in MtpDevice, stop
the loader thread's event loop to avoid this situation.
See qtbase commit c8277b6e532
John Maguire
Jim Broadus
Jim Broadus
Clementine Buildbot
Pavel Liavonau
Jonas Kvinge