Короткий ответ
Удаление fuse , вероятно, приведет к невозможности монтировать файловую систему.
FUSE является Filesystem в Userspace , который означает , что есть в пользовательском пространстве программы , которая обрабатывает все операции , выполняемые на этой конкретной файловой системе ( в то время как без плавких поддержки файловой системы работает в) ядрах системы . Это может быть ntfs-3g в вашем случае; даже если это не так, история в целом такая же.
Все конкретные реализации FUSE зависят от пакета fuse , и среди них есть ntfs-3g (ну, формально это предварительная зависимость, но здесь нет никакой разницы). Это означает, что вы не можете удалить fuse и заставить работать ntfs-3g (или другую программу FUSE).
Что действительно беспокоит вас, так это наличие файлов .fuse_hidden (сравните: проблема XY). Остальная часть моего ответа посвящена этой проблеме.
Контекст
Похоже, что вы можете игнорировать файлы .fuse_hidden , как указано здесь: Что такое файл .fuse_hidden и почему они существуют?
Ответ на Как удалить .fuse_hidden файлы? сравнивает поведение FUSE с NFS:
Это похоже на то, что происходит, когда вы удаляете файл, открытый другой системой при монтировании NFS.
и поведение NFS объясняется здесь. Оттуда:
Что происходит, когда файл открывается клиентом и удаляется? Файл должен иметь имя, чтобы клиент, у которого он открыт, мог получить к нему доступ. Но когда файл удален, ожидается, что после этого файла с таким именем больше не будет. Таким образом, серверы NFS превращают удаление открытого файла в переименование: файл переименовывается в .nfs… (.nfs за которым следует строка букв и цифр).
Это все потому, что файл в Linux можно удалить, пока он открыт процессом. Этот механизм работает с локальными файловыми системами на основе inode (например, с семейством ext), но его необходимо каким-то образом эмулировать, если доступ к файлам зависит только от их имен. Я считаю, что ситуация с NTFS несколько сложна. Вы можете найти некоторые интересные комментарии и ссылки по ссылке выше.
Ну, ntfs-3g может имитировать общее поведение Windows и запрещать удаление файла, когда он используется. Проблема заключается в том, что многие программы Linux ожидают, что они могут удалить файл, который они все еще используют. Это довольно умно.
Предположим, вашей программе нужен временный файл. Он создает один, открывает его и немедленно удаляет - и Linux это разрешает. Отныне задача фактического освобождения дискового пространства (когда файл больше не нужен) - чужая задача: ядро или FUSE. Эта задача будет выполнена изящно, даже если ваша программа неожиданно умирает или насильственно убивается.
С другой стороны, если ваша программа не может удалить файл заранее, ее работа по-прежнему заключается в ее очистке; неожиданное завершение может оставить "заброшенный" временный файл. А что если кто-нибудь еще откроет тот же файл? Тогда ваша программа не может удалить его, даже когда все готово, и все в порядке.
Хорошо использовать этот способ обработки файлов в Linux. Файлы типа .fuse_hidden или .nfs являются ценой этой философии, и в конечном итоге они будут удалены. Но скажем, что-то пошло не так, и они не будут. Их по-прежнему относительно легко обнаружить во время ручного обслуживания, в то время как в Windows вы можете "оставить" файлы и не знать об этом. Способ Linux кажется мне гораздо более аккуратным подходом.
Некоторые тесты
Мой испытательный стенд:
# 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
Подготовка точек монтирования:
# mkdir /mnt/ext4 /mnt/ntfs
Подготовка файловых систем:
# truncate -s 20M image-ext4
# truncate -s 20M image-ntfs
# mkfs.ext4 -Fq image-ext4
# mkfs.ntfs -FqQ image-ntfs
( Болтливый вывод mkfs.ntfs опущен.)
Монтаж:
# mount image-ext4 /mnt/ext4/
# mount image-ntfs /mnt/ntfs/
Начальное использование диска:
# 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
Создание файлов:
# 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
Использование диска:
# 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
Открытие файлов, затем удаление:
# exec 3<> /mnt/ext4/file
# exec 4<> /mnt/ntfs/file
# rm /mnt/ext4/file /mnt/ntfs/file
Использование диска:
# 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
Таким образом, несмотря на удаление, дисковое пространство все еще используется. Это потому, что файлы все еще открыты.
Актуальные файлы:
# ls -A /mnt/ext4/ /mnt/ntfs/
/mnt/ext4/:
lost+found
/mnt/ntfs/:
.fuse_hidden0000000200000001
На этом этапе я делаю копии файловых систем (для последующего сравнения). В общем, я знаю, что не следует делать это, пока они монтируются, но идея состоит в том, чтобы смоделировать полный сброс до того, как я закрою файлы. Тем не менее, я хочу, чтобы скопированные файловые системы были чистыми, отсюда и команда sync . Кроме того, --reflink=always позволяет мне делать копии, похожие на снимки, в моей файловой системе Btrfs, где хранятся image-ext4 и image-ntfs ; в этом тесте обычный cp должен работать.
# sync
# cp --reflink=always image-ext4 copy-ext4
# cp --reflink=always image-ntfs copy-ntfs
Я могу проверить, является ли copy-ext4 чистым:
# fsck.ext4 copy-ext4
e2fsck 1.42.13 (17-May-2015)
copy-ext4: clean, 11/5136 files, 1849/20480 blocks
К сожалению, нет fsck.ntfs .
Давайте продолжим с оригинальными файловыми системами. Закрытие файлов:
# exec 3>&-
# exec 4>&-
Использование диска:
# 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
Содержание:
# ls -A /mnt/ext4/ /mnt/ntfs/
/mnt/ext4/:
lost+found
/mnt/ntfs/:
Файл .fuse_hidden больше не существует, и дисковое пространство снова свободно. Файл исчезает, когда он больше не нужен.
Давайте посмотрим, что происходит после имитации сброса, когда файлы не были закрыты должным образом. Монтажные копии:
# umount /mnt/ext4 /mnt/ntfs
# mount copy-ext4 /mnt/ext4/
# mount copy-ntfs /mnt/ntfs/
Использование диска:
# 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
Актуальные файлы:
# ls -A /mnt/ext4/ /mnt/ntfs/
/mnt/ext4/:
lost+found
/mnt/ntfs/:
.fuse_hidden0000000200000001
Так что это сценарий, когда вы должны вручную удалить файл .fuse_hidden . Обратите внимание, что если бы ntfs-3g не создавал такой файл и вообще отказывал в удалении, у вас теперь был бы оставшийся файл со старым именем; Вы бы сделали это даже без перезагрузки, а это означает еще больше обслуживания.
Я считаю, что файловые системы, основанные на инодах, вообще не нуждаются в таком обслуживании.
Очистка:
# umount /mnt/ext4 /mnt/ntfs
# rmdir /mnt/ext4/ /mnt/ntfs/
# rm image-ext4 copy-ext4 image-ntfs copy-ntfs
