Проверка синтаксиса ~ / .config / mimeapps.list
клочок одного файла имеет какие-либо надежды на безопасность только до тех пор, пока вы не можете гарантировать, что другие копии этого файла никогда не были сделаны.Это может хорошо работать для действительно больших файлов (фильмов) - при условии, что вы не перекодируете их, и совсем не хорошо для небольших файлов, документов и всего, с чем вы действительно работаете.
Каждый раз, когда вы нажимаете «Сохранить», у вас появляется еще одна копия. Поскольку при сохранении файл обрезается до 0 байтов и записывается новый файл - обычно в физически другом месте. Даже файловая система больше не знает, где находилась старая копия, поэтому ее невозможно удалить с помощью shred или какой-либо другой утилиты.
Таким образом, вместо этого вы перезаписываете все свободное пространство. Это намного лучше, чем измельчение отдельных файлов, но в нем есть свои подводные камни ... вам нужно быть пользователем root, чтобы также перезаписать корневой резерв, а файловые системы вообще не любят быть заполненными - любые другие записи, происходящие в то же время время не удастся, таким образом, вы закончите фактическую потерю данных в процессе.
Примерно так:
truncate -s 1E sparsefile
shred -v -n 1 sparsefile
sync # other programs will lose data at this point
rm sparsefile
С SSD вы получаете zerofree как встроенную функцию, fstrim / discard делает именно это, быстро и легко избавляясь от свободного места. По сути, с SSD вы не сможете восстановить удаленные файлы после того, как произошла обрезка.
Это безопасно? Это зависит от файловой системы и размера файла, от которого вы хотите избавиться. В некоторых файловых системах есть укромные уголки и трещины, такие как несколько небольших файлов, совместно использующих один блок, и это пространство не будет перезаписано при создании одного колоссального большого файла, полного случайных данных. Также могут быть другие следы, такие как оставшееся имя файла в записи каталога ...
Вы не можете победить перезапись всего устройства один раз.
# backup everything
blkdiscard /dev/sda # SSD
shred -v -n 1 /dev/sda # HDD
# create partitions, filesystems, restore backup
Как вы сказали, Ассоциация между типами MIME и спецификацией приложений является соответствующей спецификацией, но она не описывает формат файла подробно. Тем не менее, он зависит от спецификации Desktop Entry для формата файла; это не особенно явно, но я думаю, что
УпоминаниеThe value is a semicolon-separated list of desktop file IDs (as defined in the desktop entry spec).
(относительно формата пар ключ-значение )является хорошим показателем.
Существует инструмент проверки для файлов .desktop, desktop-file-validate, но его нельзя использовать в списках типов MIME, поскольку типы MIME не являются действительными ключами файлов .desktop.
Глядя на код, например. дляxdg-openпоказывает, что формат файла очень прост :инструменты ищут ключи в разделах, и они делают это, начиная с верхней части соответствующего файла, ища первое вхождение раздела между квадратами скобки, затем первое вхождение ключа, за которым следует знак «=». Таким образом, при поиске данного ключа в данном разделе будет использоваться первая строка, соответствующая ключу, который также находится в правильном разделе.
Это имеет ряд последствий:
- разделы могут повторяться
- могут присутствовать бессмысленные строки, они будут проигнорированы
- любая строка, не содержащая «=» или квадратных скобок, фактически является комментарием
Связь между типами MIME и спецификацией приложений наиболее близка к синтаксическому определению файла, который я смог найти.
Синтаксис «раздел» действительно очень схематичен -например, нет упоминания о комментариях.