Раньше я просто нажимал клавишу Удалить kbd> на выбранных файлах на Nautilus
, и тогда он удалял файлы без подтверждения. Это было очень удобно.
Позже я решил, что моя корзина может содержать конфиденциальные файлы, и поэтому переместил ее в папку eCryptfs Private
, и создал символическую ссылку ~/.local/share
вместо нее.
После этого, когда я удаляю kbd> файлы, которые находятся внутри eCryptfs
, поведение, как и ожидалось, никаких проблем. С другой стороны, когда я пытаюсь удалить файлы в моем домашнем каталоге, но за пределами eCryptfs, я получаю это сообщение:
Такое же поведение наблюдается при удалении элементов с другого диска ...
Есть ли обходной путь, чтобы просто автоматически поместить его в мой зашифрованный мусор в любом случае, даже если он принадлежит другому / незашифрованному диску / монтированию?
Если это действительно невозможно сделать, тогда два Trashes
возможно? Один для зашифрованных файлов и другой для незашифрованных?
Когда Вы перемещаете файлы в мусор с Наутилусом, или gvfs-trash
они никогда перемещены в другой объем. Они - “ rename
d” к другой записи каталога (в каталоге мусора) на том же объеме. Обратите внимание, что документация той функции объясняет, что файлы не могут быть “renamed” на различные объемы или точки монтирования.
Это означает, что перемещение файла к мусору от зашифрованного тома (ли eCryptFS, dm-crypt/LUKS или чем-либо еще, что требует, чтобы ядро смонтировало что-то) будет никогда результат в дешифровании файла. Следовательно я не думаю, что выгодно связаться ~/.local/share/Trash
с чем-то под ~/Private
. Можно протестировать это со следующими командами:
cd ~/Private
touch foobar.txt
gvfs-trash foobar.txt
ls -1 ~/.local/share/Trash/files/foobar.txt* ~/Private/.Trash-*/files/foobar.txt*
, который должен дать Вам что-то как:
ls: cannot access /home/david/.local/share/Trash/files/foobar.txt*: No such file or directory
/home/david/Private/.Trash-1000/files/foobar.txt
<час> Интересно файл не поднимается в моей виртуальной папке "Удаленные":
$ gvfs-ls trash:// | grep -cwFe foobar.txt
0
(В то время как те же работы, когда я делаю gvfs-trash ~/foobar.txt
.)
По причине, обрисованной в общих чертах выше, я думаю, что невозможно с текущей реализацией gvfs-мусора иметь мусор на другом объеме, чем исходный объем файла, отправленного в мусор.