Итак, у вас есть это:
Файловый менеджер представляет те сообщения об ошибках, которые приходят от GVfs, которая передает информацию из libmtp .
Предотвращение появления файловых менеджеров
К сожалению, я еще не нашел способ подавления всплывающих окон с ошибками в файловом менеджере GNOME / MATE / Cinnamon. Возможно, когда-нибудь я посмотрю исходный код, чтобы увидеть, где ошибка может быть отключена или перехвачена.
Поскольку у меня нет ответа на этот вопрос, давайте перейдем к вашему следующему лучшему приемлемому варианту, который ...
Закрытие всплывающих окон файлового менеджера по команде
Вот скрипт, который можно использовать для очистки всплывающих окон в GNOME, MATE и Cinnamon:
#!/bin/bash function list_empty_windows() { wmctrl -lp | awk "}" } function list_wm_pids() { ps aux | grep cinnamon | perl -pe 's/.*\+\s+(\d+)\s+.*/\1/' pidof nautilus | tr ' ' '\n' pidof caja | tr ' ' '\n' pidof nemo | tr ' ' '\n' } function list_popup_windows() { local empty_window_file=$(mktemp) local window_manager_pid_file=$(mktemp) list_empty_windows > "$empty_window_file" list_wm_pids | sort > "$window_manager_pid_file" join "$empty_window_file" "$window_manager_pid_file" } function main() { list_popup_windows | cut -d ' ' -f 2 | xargs -n1 -P100 wmctrl -ic } main Если вы хотите запомнить простую команду, они закроют все окна в вашем файловом менеджере и заставят ваш рабочий стол перезапустить ваш файловый менеджер:
- ГНОМ:
killall nautilus - ПРИЯТЕЛЬ:
killall caja - Корица:
killall nemo
Отключение автонастройки Google Pixel
Кажется, не существует способа игнорировать только Google Pixel.
Я не рекомендую это, и я не проверял это сам, но чтобы выделить Google Pixel, вам, возможно, придется закомментировать вендор продукта 18d1 4ee1 (Google Pixel) и вендор продукта 18ee 1 4ee2 (Google Pixel отладка) правила и hwdb.
Вы можете найти записи с помощью этой команды:
grep -ri '18d1.*4ee[12]' /lib/udev После закомментирования записей udev в Google Pixel может потребоваться перезапустить среду рабочего стола, перезагрузить компьютер и / или выполнить некоторую комбинацию следующих команд:
sudo udevadm hwdb --update sudo udevadm control --reload-rules sudo udevadm trigger Опять же, это не проверено, и я не рекомендую это, особенно потому, что для того, чтобы снова смонтировать Google Pixel, вам придется отменить изменения udev, сделанные вручную.
объяснение
Согласно /var/log/syslogGNOME, ошибка появляется, потому что USB-устройство исчезло при второй попытке его инициализации:
Jan 24 01:32:41 node51 kernel: [613604.065259] usb 3-2: new SuperSpeed USB device number 96 using xhci_hcd Jan 24 01:32:41 node51 kernel: [613604.082734] usb 3-2: New USB device found, idVendor=18d1, idProduct=4ee1 Jan 24 01:32:41 node51 kernel: [613604.082739] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 24 01:32:41 node51 kernel: [613604.082741] usb 3-2: Product: Pixel Jan 24 01:32:41 node51 kernel: [613604.082743] usb 3-2: Manufacturer: Google Jan 24 01:32:41 node51 kernel: [613604.082745] usb 3-2: SerialNumber: XXXXXXXXXXXX Jan 24 01:32:41 node51 kernel: [613604.083855] usb 3-2: Enable of device-initiated U1 failed. Jan 24 01:32:41 node51 kernel: [613604.084154] usb 3-2: Enable of device-initiated U2 failed. Jan 24 01:32:42 node51 org.gtk.vfs.Daemon[4988]: Device 0 (VID=18d1 and PID=4ee1) is a Google Inc (for LG Electronics/Samsung) Nexus 4/5/7/10 (MTP). Jan 24 01:32:43 node51 org.gtk.vfs.GPhoto2VolumeMonitor[4988]: (process:5256): GVFS-GPhoto2-WARNING **: device (null) has no BUSNUM property, ignoring Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: PTP_ERROR_IO: failed to open session, trying again after resetting USB interface Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: LIBMTP libusb: Attempt to reset device Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: inep: usb_get_endpoint_status(): No such device Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: outep: usb_get_endpoint_status(): No such device Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: libusb_open() failed!: No such device Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: LIBMTP PANIC: Could not init USB on second attempt Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: ** (gvfsd:5151): WARNING **: dbus_mount_reply: Error from org.gtk.vfs.Mountable.mount(): Unable to open MTP device '[usb:003,096]' В приведенном выше примере GVfs через libmtp идентифицировали устройство 096 с шиной USB 003 как устройство Google Pixel, но устройство Google Pixel уже отключилось. В следующий раз, когда Google Pixel подключится, Linux назначит новый идентификатор устройства.
Ошибка libmtp, потому что он все еще пытается работать с исчезнувшим устройством. GVfs обнаруживает ошибку и пересылает ее в файлы GNOME или какой-либо другой файловый менеджер на основе GNOME.
Кто виноват?
Исходя из того, что я обнаружил, у них есть возможности для улучшения:
libmtp
libmtp, вероятно, является наиболее ответственным в возникновении этой проблемы.
Это должно улучшить обработку ошибок, когда устройство MTP подключено и внезапно отключено. Ошибка должна быть передана, только если устройство все еще существует. Если USB-устройство не существует, попытаться сбросить его не имеет смысла.
Android
Android может улучшить реализацию MTP, чтобы он не отключался сразу после подключения к компьютеру.
Сообщить о проблемах на Android
Наутилус / Каха / Немо
Было бы неплохо, если бы эти программы предлагали подавлять сообщения об ошибках или отображать их менее всплывающим образом.
Сообщить о проблемах в GNOME
Сообщить о проблемах в MATE Caja
Сообщить о проблемах в Linux Mint Nemo