Итак, у вас есть это:
Файловый менеджер представляет те сообщения об ошибках, которые приходят от GVfs, которая передает информацию из libmtp.
Предотвращение появления файловых менеджеров
К сожалению, я еще не нашел способ подавления всплывающих окон с ошибками в файловом менеджере GNOME/MATE/Cinnamon. Возможно, когда-нибудь я посмотрю исходный код, чтобы увидеть, где ошибка может быть отключена или перехвачена.
Поскольку у меня нет ответа на этот вопрос, давайте перейдем к вашему следующему лучшему приемлемому варианту, который ...
Закрытие всплывающих окон файлового менеджера по команде
Вот скрипт, который можно использовать для очистки всплывающих окон в GNOME, MATE и Cinnamon:
#!/bin/bash
function list_empty_windows() {
wmctrl -lp | awk "{if(\$5==\"\"){print\$3,\$1}}"
}
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
Если вы хотите запомнить простую команду, они закроют все окна в вашем файловом менеджере и заставят ваш рабочий стол перезапустить ваш файловый менеджер:
- GNOME:
killall nautilus
- MATE:
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/syslog , GNOME выдает ошибку, потому что устройство 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-устройство не существует, попытаться сбросить его не имеет смысла.
Сообщить о проблемах в libmtp
Android
Android может улучшить реализацию MTP, чтобы он не отключался сразу после подключения к компьютеру.
Сообщить о проблемах на Android
Наутилус / Каха / Немо
Было бы неплохо, если бы эти программы предлагали подавлять сообщения об ошибках или отображать их менее всплывающим образом.
Сообщить о проблемах в GNOME
Сообщить о проблемах MATE Caja
Сообщить о проблемах в Linux Mint Nemo
