Kurze Antwort
Durch das Entfernen fusewird das Dateisystem möglicherweise nicht bereitgestellt.
FUSE ist Filesystem in Userspace. Dies bedeutet, dass es ein Userspace-Programm gibt, das alle Operationen ausführt, die auf diesem bestimmten Dateisystem ausgeführt werden (während die Unterstützung von nicht-fuse Dateisystemen im Kernelspace funktioniert). Es kann ntfs-3gin Ihrem Fall sein; Selbst wenn nicht, ist die Geschichte im Allgemeinen die gleiche.
Alle spezifischen FUSE-Implementierungen hängen vom fusePaket ab und ntfs-3gsind darunter (naja, formal ist es eine Abhängigkeit von der Abhängigkeit, aber hier spielt es keine Rolle ). Dies bedeutet, dass Sie nicht entfernen können fuseund haben ntfs-3g(oder ein anderes Programm FUSE) arbeiten.
Was Sie wirklich stört, ist das Vorhandensein von .fuse_hiddenDateien (vergleiche: XY-Problem ). Der Rest meiner Antwort befasst sich mit diesem Problem.
Der Kontext
Es sieht so aus .fuse_hidden, als könnten Sie Dateien ignorieren, wie hier angegeben: Was ist eine .fuse_hiddenDatei und warum gibt es sie?
Die Antwort auf Wie lösche ich .fuse_hiddenDateien? vergleicht das Verhalten von FUSE mit NFS:
Dies ist ähnlich wie beim Löschen einer Datei, die auf einem NFS-Mount von einem anderen System geöffnet wurde.
und NFS-Verhalten wird hier erklärt . Von dort:
Was passiert, wenn eine Datei von einem Client geöffnet und gelöscht wird? Die Datei muss weiterhin einen Namen haben, damit der Client, der sie geöffnet hat, weiterhin darauf zugreifen kann. Wenn jedoch eine Datei gelöscht wird, ist zu erwarten, dass danach keine weitere Datei mit diesem Namen mehr vorhanden ist. So verwandeln NFS-Server das Löschen einer geöffneten Datei in eine Umbenennung: Die Datei wird in umbenannt
.nfs…(.nfsgefolgt von einer Folge von Buchstaben und Ziffern).
Das liegt daran, dass eine Datei in Linux gelöscht werden kann, während sie von einem Prozess geöffnet wird . Dieser Mechanismus funktioniert von vornherein mit inode-basierten lokalen Dateisystemen (wie der ext-Familie), muss aber irgendwie emuliert werden, wenn der Zugriff auf Dateien nur von deren Namen abhängt. Ich glaube, die Situation mit NTFS ist etwas kompliziert. Unter dem Link oben finden Sie einige interessante Kommentare und Links.
Nun, ntfs-3gkönnte das allgemeine Verhalten von Windows nachahmen und das Entfernen der Datei verweigern, wenn sie verwendet wird. Das Problem ist, viele Linux - Programme erwarten können sie die Datei entfernen sie noch verwenden. Es ist ziemlich schlau.
Nehmen wir an, Ihr Programm benötigt eine temporäre Datei. Es erstellt eines, öffnet es und entfernt es sofort - und Linux lässt dies zu. Von nun an ist es die Aufgabe eines anderen, den Plattenspeicherplatz tatsächlich freizugeben (wenn die Datei nicht mehr benötigt wird): der Kernel oder FUSE. Diese Aufgabe wird auch dann ordnungsgemäß erledigt, wenn Ihr Programm unerwartet stirbt oder gewaltsam getötet wird.
Wenn Ihr Programm die Datei jedoch vorher nicht entfernen kann, ist es nach wie vor seine Aufgabe zu säubern. Eine unerwartete Beendigung kann die "aufgegebene" temporäre Datei verlassen. Und was ist, wenn jemand anderes dieselbe Datei geöffnet hat? Dann kann Ihr Programm es nicht entfernen, selbst wenn es fertig ist und alles in Ordnung ist.
Es ist gut, diese Linux-Methode zum Umgang mit Dateien beizubehalten. Dateien wie .fuse_hiddenoder .nfssind die Kosten dieser Philosophie und werden letztendlich entfernt. Aber sagen wir mal, dass etwas schief gelaufen ist und sie nicht. Es ist immer noch relativ einfach, sie während der manuellen Wartung zu erkennen. In Windows haben Sie möglicherweise Dateien "aufgegeben" und wissen es nicht. Linux-Weg scheint mir viel aufgeräumter.
Einige Tests
Mein Testbett:
# whoami root # cat /etc/issue Ubuntu 16.04.2 LTS \n \l # uname -a Linux foobar 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux # dpkg -l | grep ntfs-3g ii ntfs-3g 1:2015.3.14AR.1-1ubuntu0.1 amd64 read/write NTFS driver for FUSE Mountpoints vorbereiten:
# mkdir /mnt/ext4 /mnt/ntfs Dateisysteme vorbereiten:
# truncate -s 20M image-ext4 # truncate -s 20M image-ntfs # mkfs.ext4 -Fq image-ext4 # mkfs.ntfs -FqQ image-ntfs (Geschwätzige Ausgabe von mkfs.ntfsweggelassen.)
Montage:
# mount image-ext4 /mnt/ext4/ # mount image-ntfs /mnt/ntfs/ Ursprüngliche Festplattennutzung:
# df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 172K 17M 1% /mnt/ext4 /dev/loop1 20M 2.5M 18M 13% /mnt/ntfs Dateien erstellen:
# dd if=/dev/urandom bs=1M count=10 | tee /mnt/ext4/file > /mnt/ntfs/file 10+0 records in 10+0 records out 10485760 bytes (10 MB, 10 MiB) copied, 0.645865 s, 16.2 MB/s Festplattennutzung:
# df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 11M 6.8M 60% /mnt/ext4 /dev/loop1 20M 13M 7.6M 63% /mnt/ntfs Dateien öffnen und dann entfernen:
# exec 3<> /mnt/ext4/file # exec 4<> /mnt/ntfs/file # rm /mnt/ext4/file /mnt/ntfs/file Festplattennutzung:
# df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 11M 6.8M 60% /mnt/ext4 /dev/loop1 20M 13M 7.6M 63% /mnt/ntfs Trotz des Entfernens wird der Speicherplatz trotzdem verwendet. Dies liegt daran, dass die Dateien noch geöffnet sind.
Aktuelle Dateien:
# ls -A /mnt/ext4/ /mnt/ntfs/ /mnt/ext4/: lost+found /mnt/ntfs/: .fuse_hidden0000000200000001 An diesem Punkt mache ich Kopien der Dateisysteme (zum späteren Vergleich). Ich weiß im Allgemeinen, dass ich dies nicht tun sollte, während sie eingehängt sind. Die Idee ist, einen Hard-Reset zu simulieren, bevor ich die Dateien schließe. Trotzdem möchte ich, dass die kopierten Dateisysteme sauber sind, daher der syncBefehl. Zusätzlich --reflink=alwayserlaubt mir die Option, Snapshot-ähnliche Kopien auf meinem Btrfs-Dateisystem zu erstellen, in denen image-ext4und image-ntfsgespeichert werden. In diesem Test cpsollte die Ebene auch funktionieren.
# sync # cp --reflink=always image-ext4 copy-ext4 # cp --reflink=always image-ntfs copy-ntfs Ich kann überprüfen, ob copy-ext4es sauber ist:
# fsck.ext4 copy-ext4 e2fsck 1.42.13 (17-May-2015) copy-ext4: clean, 11/5136 files, 1849/20480 blocks Leider gibt es keine fsck.ntfs.
Fahren wir mit den ursprünglichen Dateisystemen fort. Schließen der Dateien:
# exec 3>&- # exec 4>&- Festplattennutzung:
# df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 172K 17M 1% /mnt/ext4 /dev/loop1 20M 2.5M 18M 13% /mnt/ntfs Inhalt:
# ls -A /mnt/ext4/ /mnt/ntfs/ /mnt/ext4/: lost+found /mnt/ntfs/: Die .fuse_hiddenDatei ist nicht mehr vorhanden und der Speicherplatz ist wieder frei. Die Datei wird ausgeblendet, wenn sie nicht mehr benötigt wird.
Mal sehen, was nach dem simulierten Reset passiert, wenn die Dateien nicht richtig geschlossen wurden. Montagekopien:
# umount /mnt/ext4 /mnt/ntfs # mount copy-ext4 /mnt/ext4/ # mount copy-ntfs /mnt/ntfs/ Festplattennutzung:
# df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 172K 17M 1% /mnt/ext4 /dev/loop1 20M 13M 7.6M 63% /mnt/ntfs Aktuelle Dateien:
# ls -A /mnt/ext4/ /mnt/ntfs/ /mnt/ext4/: lost+found /mnt/ntfs/: .fuse_hidden0000000200000001 Dies ist also ein Szenario, in dem Sie .fuse_hiddenDateien manuell entfernen sollten . Wenn Sie ntfs-3geine solche Datei nicht erstellt und das Entfernen von vornherein abgelehnt haben, haben Sie jetzt eine übrig gebliebene Datei mit ihrem alten Namen. Sie hätten es auch ohne Reset und dies bedeutet noch mehr Wartung.
Ich glaube, dass inode-basierte Dateisysteme eine solche Wartung überhaupt nicht benötigen.
Reinigung:
# umount /mnt/ext4 /mnt/ntfs # rmdir /mnt/ext4/ /mnt/ntfs/ # rm image-ext4 copy-ext4 image-ntfs copy-ntfs