Donc vous avez ceci :
Le gestionnaire de fichiers présente ces messages d'erreur, qui proviennent de GVfs, qui relaye les informations de libmtp.
Éviter les fenêtres contextuelles d'erreur du gestionnaire de fichiers
Malheureusement, je n'ai pas encore découvert de moyen de supprimer les fenêtres contextuelles d'erreur dans le gestionnaire de fichiers GNOME/MATE/Cinnamon. Peut-être qu'un jour, j'examinerai le code source pour voir où l'erreur peut être désactivée ou interceptée.
Puisque je n'ai pas de réponse à cela, passons à votre meilleure option acceptable suivante, qui est…
Fermer les fenêtres contextuelles du gestionnaire de fichiers par commande
Voici un script qui peut être utilisé pour effacer les fenêtres contextuelles sur GNOME, MATE et 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
Si vous voulez une commande facile à retenir, cela fermera toutes les fenêtres de votre gestionnaire de fichiers et fera redémarrer votre bureau :
- GNOME :
killall nautilus - MATE :
killall caja - Cannelle :
killall nemo
Désactiver le montage automatique de Google Pixel
Il ne semble pas y avoir de moyen de se souvenir d'ignorer uniquement Google Pixel.
Je ne le recommande pas, et je ne l'ai pas testé moi-même, mais pour distinguer Google Pixel, vous devrez peut-être commenter le produit 4ee1 du fournisseur 18d1 (Google Pixel) et le produit 4ee2 du fournisseur 18d1 (débogage Google Pixel) dans le udev règles et hwdb.
Vous pouvez trouver les enregistrements avec cette commande :
grep -ri '18d1.*4ee[12]' /lib/udev
Après avoir commenté les enregistrements udev de Google Pixel, vous devrez peut-être redémarrer votre environnement de bureau, redémarrer et/ou exécuter une combinaison des commandes suivantes :
sudo udevadm hwdb --update
sudo udevadm control --reload-rules
sudo udevadm trigger
Encore une fois, cela n'a pas été testé, et je ne le recommande pas, en particulier parce que pour remonter Google Pixel, vous devrez annuler les modifications manuelles d'udev.
Explication
Selon /var/log/syslog , GNOME fait apparaître l'erreur car le périphérique USB a disparu lors de la deuxième tentative d'initialisation :
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]'
Dans l'exemple ci-dessus, GVfs via libmtp a identifié le périphérique 096 du bus USB 003 comme étant le périphérique Google Pixel, mais le périphérique Google Pixel s'était déjà déconnecté. La prochaine fois que Google Pixel se reconnectera, Linux aura attribué un nouvel ID d'appareil.
libmtp génère des erreurs car il essaie toujours de fonctionner avec le périphérique qui a disparu. GVfs récupère l'erreur et la transmet à GNOME Files ou à un autre gestionnaire de fichiers basé sur GNOME.
Qui est en faute ?
D'après ce que j'ai découvert, ceux-ci peuvent être améliorés :
libmtp
libmtp est probablement le plus responsable de ce problème.
Cela devrait améliorer la gestion des erreurs lorsqu'un périphérique MTP est connecté et soudainement déconnecté. L'erreur ne doit être transmise que si le périphérique existe toujours. Si le périphérique USB n'existe pas, il est inutile d'essayer de le réinitialiser.
Android
Android pourrait améliorer son implémentation MTP afin qu'il ne se déconnecte pas immédiatement lors de la connexion à un ordinateur.
Nautilus / Caja / Nemo
Ce serait bien si ces logiciels offraient une préférence pour supprimer les messages d'erreur ou les afficher de manière moins contextuelle.
J'ai une solution de contournement pour cela sur Nemo :
Accédez à Modifier > Préférences > Comportement et sur la gestion des médias décochez "Monter automatiquement le support amovible lors de son insertion et au démarrage".
Lorsque vous avez terminé de charger votre téléphone, vous pouvez réactiver l'option pour reprendre le comportement par défaut.