Bind-mount kann Trash nicht nutzen

[buhtz]

Ich nutze eine HDD (/mnt/hdd) und SSD (/) in meinem System (Debian 11 stable mit XFCE) und hab da diverse bind-mounts

Code: Alles auswählen

# Die SSD
UUID=456a312c-147f-4cfd-a8f3-198009027285 /               ext4    errors=remount-ro 0       1
# Die HDD
UUID=c7aca0a7-89ed-43f0-a4f9-c744dfe673e0 /mnt/hdd        ext4    defaults,user,exec        0       2

# bind mounts
/mnt/hdd/Dokumente /home/user/Dokumente none defaults,bind 0 0
/mnt/hdd/Downloads /home/user/Downloads none defaults,bind 0 0
/mnt/hdd/Musik /home/user/Musik none defaults,bind 0 0
# ...etc, insgesamt 7 Stück

Wenn ich mit dem Dateinamaner Thunar (XFCE default glaub ich) oder pcmanfm-qt eine Datei Lösche, kann ich sie nur "echt" (also alla `rm`) löschen. Der Papierkorb geht nicht.
OK, das liegt wohl daran, dass der Trash auf einer anderen Partition liegt? So ganz kapier ich das Problem aber ehrlich gesagt nicht.

Kann man das irgendwie umschiffen und beheben?
Es wäre OK, wenn das "Löschen" (also verschieben in den Trash) einige Zeit in Anspruch nimmt, da ja die Dateien real verschoben werden müssen.
Oder ich kann den Trash auch auf die HDD legen, wenn das hilft. Wie eigentlich?
Oder ist das Problem spezifisch für jeden einzelnen bind-mount?

[smutbert]

OK, das liegt wohl daran, dass der Trash auf einer anderen Partition liegt? [...]

Genau das vermute ich.

Ich glaube nicht, dass sich alle Dateimanager exakt gleich verhalten, aber dass Dateien nicht über Dateisystemgrenzen hinweg in den Papierkorb verschoben werden dürfte einigermaßen einheitlich sein.
Von Gnome/nautilus kenne ich es so, dass beim Löschen von Dateien auf einem anderen Dateisystem, versucht wird im Wurzelverzeichnis dieses Dateisystems ein Papierkorbervzeichnis (».Trash-$UID«) anzulegen und die Dateien dorthin zu verschieben und wenn das nicht möglich ist, wird statt dem Verschieben in den Papierkorb das endgültige Löschen angeboten.

Weil es sich mit btrfs und seinen subvolumes etwas merkwürdig verhält, hätte ich auch lieber ein anderen Verhalten gehabt, aber ich kenne keinen Weg das anzupassen.
(Für mich war es ein klitzekleiner Beitrag zu meiner Entscheidung Gnome, Xfce & Co. den Rücken zu kehren.)

[buhtz]

dass Dateien nicht über Dateisystemgrenzen hinweg in den Papierkorb verschoben werden dürfte einigermaßen einheitlich sein.

Aber warum geht das nicht? Was ist der Hintergrund?
Technisch erscheint mir das trivial, nur dass es eben länger dauert, weil hier Dateien wirklich verschoben werden müssen und nicht nur Einträge in einer FAT verändert werden.

Aber selbst das lässt sich umgehen: Der Dateimanager könnte die Dateien sofort in einen temporären Trash auf der selben Partition verschieben und danach diesen im Hintergrund "gemütlich" und ohne den User zu belästigen in den primären Trash auf der anderen Partition schieben.

Aber ich stelle es mir vermutlich zu einfach vor, oder?

[smutbert]

Da kann ich auch nur mutmaßen, aber ich kann gut verstehen, wenn die Entwickler das ganze möglichst einfach halten möchten

Was ist etwa, wenn die zu löschende Datei Metadaten besitzt (z. B. erweiterte Dateisystemattribute), die von dem Dateisystem in dem der Papierkorb liegt nicht unterstützt werden oder wenn die Datei größer ist als auf dem anderen Dateisystem möglich oder wenn es eine Sparse-Datei ist, die auf dem Dateisystem in dem der Papierkorb liegt nicht möglich ist

Ein weiterer möglicher Gedanke der Entwickler wäre der an USB-Sticks – wenn man am eigenen USB-Stick Dateien in den Papierkorb verschiebt, während man an einem x-beliebigen Computer arbeitet, den man vielleicht nie wieder sieht, ist es natürlich sinnvoller, wenn der Papierkorb auf dem Stick liegt.

[buhtz]

ist es natürlich sinnvoller, wenn der Papierkorb auf dem Stick liegt.

Gut das wäre mir auch recht, wenn ich für jede Partition einen eigenen Papierkorb habe.
Aber auch das habe ich ja nicht.

Lassen wir mal das Ein-Trash-für-alle-Partitionen bei Seite.

Neues Problem: Es wird nicht für jede Partition ein eigener Trash angelegt.

Frage: Ist das eine Sache der Dateimanager, oder einer anderen Komponente? Wo muss ich den Bug-Report öffnen bzw. die Community kontaktieren? Lohnt es sich (schon wieder!) nach einem alternativen Dateimanager zu suchen, der das kann?

[smutbert]

Das kann an den Dateisystemrechten im Wurzelverzeichnis des Dateisystems, die das Anlegen des Papierkorbverzeichnisses erlauben müssen oder auch am Mißverständnis wo das Wurzelverzeichnis des Dateisystems überhaupt ist liegen – da ist das Verhalten mit gemounteten btrfs-subvolumes zum Teil auch überraschend und soweit ich das durchschaue ähnlich wie das Verhalten mit bind-mounts.


Die richtige Anlaufstelle für einen Bug wäre der Dateimanager, wobei die Dateimanager sich wahrscheinlich an diese Richtlinien zu halten versuchen:
https://specifications.freedesktop.org/ ... atest.html

[buhtz]

Die richtige Anlaufstelle für einen Bug wäre der Dateimanager, wobei die Dateimanager sich wahrscheinlich an diese Richtlinien zu halten versuchen:
https://specifications.freedesktop.org/ ... atest.html

Danke für den Hinweis. Die Richtlinie erwähnt auch das Partitionsproblem und meint das könnte, aber muss nicht implementiert sein.

Weiß jemand einen Dateimanager der das Handeln kann?

[buhtz]

In dem Kontext stoße ich auf GVFS. Irreführender Name. Ich habe ja hier kein Gnome.
Und wozu braucht es ein "virtuelles Dateisystem", wo doch das LFS so schön standardisiert ist.
Die Schicht ist mir völlig neu.

[smutbert]

LFS kenne ich eigentlich nur als Abkürzung für „Linux from scratch“, also dem Basteln einer eigenen Linuxdistribution vor allem mit Hilfe dieser Dokumentation.
Meinst du vielleicht den Filesystem Hierarchy Standard (FHS), der beschreibt wo im Dateisystem was hingehört?


gvfs ist Teil von Gnome, insofern ist der Name nicht irreführend, was ja aber natürlich nicht heißt, dass das nicht andere Desktopumgebungen und Programme auch verwenden dürfen.
gvfs ist einfach eine Abstraktionsschicht, über die man nicht nur auf die bekannte Dateisystemstruktur zugreifen kann, die mit »/« beginnt sondern auch über Netzwerk- und andere Protokolle auf Dateien zugreifen kann.
So ist es mit gvfs zum Beispiel möglich auf die Tracks einer Audio CDs zuzugreifen als wären es wav-Dateien, oder über die diversen Protokolle (mtp, ptp) auf Fotos und andere Dateien auf Handys, Kameras, u. s. w.

[buhtz]

Danke für die Erläuterung.

pcmanfm-qt behauptet, dass sie sich nicht um den Trash kümmern, sondern dass das GVFS dafür zuständig sei.

man gvfs geht und verweist auf gvfsd-trash - wofür es dann natürlich keine manpage mehr gibt.

Code: Alles auswählen

$ ps -aux | grep gvfs
user        1531  0.0  0.1 237232  9812 ?        Ssl  21:50   0:00 /usr/libexec/gvfsd
user        1543  0.0  0.1 379924 10376 ?        Sl   21:50   0:00 /usr/libexec/gvfsd-fuse /run/user/1000/gvfs -f
user        2679  0.0  0.2 965760 16144 ?        Ssl  21:51   0:00 /usr/libexec/gvfs-udisks2-volume-monitor
user        2711  0.0  0.1 233268  8296 ?        Ssl  21:51   0:00 /usr/libexec/gvfs-goa-volume-monitor
user        2729  0.0  0.0 311764  7840 ?        Ssl  21:51   0:00 /usr/libexec/gvfs-afc-volume-monitor
user        2759  0.0  0.0 233176  6656 ?        Ssl  21:51   0:00 /usr/libexec/gvfs-mtp-volume-monitor
user        2776  0.0  0.1 235416  8140 ?        Ssl  21:51   0:00 /usr/libexec/gvfs-gphoto2-volume-monitor
user        2816  0.0  0.0 311368  7928 ?        Sl   21:51   0:00 /usr/libexec/gvfsd-trash --spawner :1.11 /org/gtk/gvfs/exec_spaw/0
user        2824  0.0  0.0 159528  5956 ?        Ssl  21:51   0:00 /usr/libexec/gvfsd-metadata
user        8525  0.0  0.0   6200   652 pts/0    S+   23:50   0:00 grep gvfs

OK, es läuft bei mir. Wo ist die config oder eine GUI oder wo setze ich da jetzt an. Soweit ich es verstehe, müsste gvfsd ja in der Lage sein partitionsspezifische Trash-Folder anzulegen.
Und wie teste ich das direkt. Wie kann ich gvfsd-trash auslösen, ohne den Umweg über einen Dateimanager machen zu müssen, der weitere diagnose-erschwerende Komponenten mit einbringt.

[smutbert]

So einfach ist das nicht, fürchte ich. Mir scheint einige der Schwierigkeiten (mit bind-mounts und mit btrfs) sind bekannt, aber nicht so leicht zu lösen und es ist wohl auch nicht klar, an welcher Stelle sie zu lösen sind, wie z. B. bei diesem mehr als 10 Jahre alten Bugreport [1].

Jedenfalls glaube ich nicht, dass du das Verhalten von gvfsd konfigurieren kannst (ohne den Quellcoder zu ändern und neu zu kompilieren).

Wenn es dir jetzt auch darum geht warum im Bind-Mount kein Trash angelegt wird, kannst du die Ursache vielleicht eingrenzen, wenn du dir nach dieser Anleitung [2] die (Debug) Meldungen während eines Löschversuchst ansiehst. Ich habe aber keine Idee welche Menge an Meldungen dich da erwartet und wie groß die Chance ist, dass tatsächlich etwas hilfreiches dabei ist.

[1] https://gitlab.gnome.org/GNOME/gvfs/-/issues/159
[2] https://wiki.gnome.org/Projects/gvfs/debugging