Master-2000 schrieb
Hat noch jemand solch ein Verhalten feststellen können?
Ja, diese Inkonsistenz bzw. Fehlverhalten geistert schon seit Jahren durch die Desktop-/Filemanager-Welt. Auch die Weiterentwicklung von gvfs in/zu GIO haben daran nichts geändert.
Papierkörbe aus Remote-Mounts (teilweise auch lokale Mounts) tauchen einfach nicht in der Liste der zu "überwachenden" Papierkorb-Orte auf, und es läßt sich nicht konfigurieren.
Im allgemeinen Papierkorb tauchen wohl weiterhin nur die Quell-Geräte auf, die auch mittels gvfs/gio-Regie gemountet werden (ext. Platten/Sticks, usw) während Netzwerk-Mounts schon seit jeher eher stiefmütterlich gehandhabt werden. NFS war in bezug auf gvfs IMHO noch nie richtig funktionierend, es kann sein, daß z.B. per SM oder SSHFS eingehängte Mounts sogar ggf. den Papierkorb richtig handhaben (habe ich nicht ausgetestet).
Mein $HOME kommt aber z.B. über NFS, und da gibt es kein Problem...
Ein paar Links zum Thema:
Ubuntu-Bugreport von 2010:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/594674
Papierkorb-Spezifikation, wird auch initial eingehalten:
http://www.ramendik.ru/docs/trashspec.html
Suchbegriffe wären z.B. "gio multiple trash locations" oder "gio trash nfs"
Meine Herangehensweise: Wenn ich Desktop-Funktionaliät nutze zur Datei-Organisation verlasse ich mich *nicht* auf Papierkörbe.
Es gibt aber auch "gute Nachrichten":
pacman -Si community/trash-cli
kann das, was der "Desktop" nicht kann:
trash-list: listet gelöschte Objekte aus wirklich allen aktiven Papierkörben
trash-rm: leert wirklich *alle* aktive Papierkörbe
trash-restore: Bietet eine Auswahlliste der wiederherstellbaren Dateien, ohne "Ort" vom aktuelle Verzeichnis aus ($HOME z.b), per "trash-restore /mnt" oder "trash-restore /" auch für gezielte bzw. alle(?) aktiven Mounts/Papierkörbe.
Das ist halt nicht so komfortabel, aber es funktioniert wenigstens...