Então você tem isso:
Ogerenciadordearquivosapresentaessasmensagensdeerro,quevêmde
Evitando pop-ups de erro no Gerenciador de arquivos
Infelizmente, ainda não descobri uma maneira de suprimir os pop-ups de erro no gerenciador de arquivos GNOME / MATE / Cinnamon. Talvez algum dia, eu olhe para o código-fonte para ver onde o erro pode ser desativado ou interceptado.
Como não tenho uma resposta para isso, vamos para a sua próxima melhor opção aceitável, que é…
Fechando Popups do Gerenciador de Arquivos por Comando
Aqui está um script que pode ser usado para limpar os pop-ups no GNOME, no MATE e no Cinnamon:
#!/bin/bash
function list_empty_windows() {
wmctrl -lp | awk "{if(\==\"\"){print\,\}}"
}
function list_wm_pids() {
ps aux | grep cinnamon | perl -pe 's/.*\+\s+(\d+)\s+.*//'
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
Se você quiser um comando fácil de lembrar, eles fecharão todas as janelas do gerenciador de arquivos e farão com que sua área de trabalho reinicie o gerenciador de arquivos:
- GNOME:
killall nautilus - MATE:
killall caja - Canela:
killall nemo
Desativando a montagem automática do Google Pixel
Parece que não há como lembrar de ignorar apenas o Google Pixel.
Eu não recomendo isso, e eu mesmo não testei isso, mas para destacar o Google Pixel, talvez seja necessário comentar o fornecedor 18d1 product 4ee1 (Google Pixel) e o fornecedor 18d1 product 4ee2 (depuração do Google Pixel) nas regras do udev e no hwdb.
Você pode encontrar os registros com este comando:
grep -ri '18d1.*4ee[12]' /lib/udev
Depois de comentar os registros do udev do Google Pixel, talvez seja necessário reiniciar o ambiente da área de trabalho, reinicializar e / ou executar uma combinação dos seguintes comandos:
sudo udevadm hwdb --update
sudo udevadm control --reload-rules
sudo udevadm trigger
Novamente, isso não foi testado, e eu não recomendo isso, especialmente porque, para montar o Google Pixel novamente, é necessário desfazer as alterações manuais do udev.
Explicação
De acordo com /var/log/syslog , o GNOME está mostrando o erro porque o dispositivo USB desapareceu na segunda tentativa de inicializá-lo:
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]'
No exemplo acima, as GVfs através da libmtp identificaram o dispositivo 096 do barramento USB 003 como o dispositivo do Google Pixel, mas o dispositivo do Google Pixel já havia se desconectado. Na próxima vez que o Google Pixel for reconectado, o Linux terá atribuído um novo ID de dispositivo.
libmtp erros porque ainda está tentando trabalhar com o dispositivo que desapareceu. GVfs pega o erro e o encaminha para o GNOME Files ou algum outro gerenciador de arquivos baseado no GNOME.
Quem está com defeito?
Com base no que descobri, eles têm espaço para melhorias:
libmtp
O libmtp é provavelmente o mais responsável por causar esse problema.
Ele deve melhorar o tratamento de erros quando um dispositivo MTP estiver conectado e desconectado de repente. O erro só deve ser passado se o dispositivo ainda existir. Se o dispositivo USB não existir, é inútil tentar redefini-lo.
Android
O Android pode melhorar sua implementação de MTP para que ele não seja desconectado imediatamente após a conexão a um computador.
Nautilus / Caja / Nemo
Seria bom se esse software oferecesse uma preferência para suprimir mensagens de erro ou exibi-las de maneira menos pop-up.
Relatar problemas ao GNOME
Relate os problemas para MATE Caja
Relatar problemas ao Linux Mint Nemo