Странный файл с невозможным именем в моем домашнем каталоге

У меня есть странный файл, который появился в моем домашнем каталоге пару дней назад:

введите описание изображения здесь

  • снимать снимки объема BTRFS, смонтированного с помощью nodatacow?
  • Как мой раздел (ext4) знает свой размер используемого / свободного пространства?
  • Странные монтажные элементы, procfs on net:
  • Перемещение 4 системных папок в 1 разделенный раздел
  • Восстановить удаленный файл, который в настоящее время записывается в
  • Почему truncate не работает для размеров выше 2043G в ext3?
  • ls в bash дает мне следующий результат:

     Âõ(\'e@\Âõ(\7@\Âõ(,e@ëQ¸8@jon.xojcA 

    В fish ls цитирует имена shell-safe по умолчанию и дает мне следующее:

     ''$'\217\302\365''(\'\''e@\'$'\217\302\365''(\7@\'$'\217\302\365''(,e@'$'\037\205\353''Q'$'\270\036''8@jon.xojcA' 

    Я не могу удалить этот файл в Dolphin, потому что он, похоже, не существует. Я думаю, в Dolphin есть ошибка, что он не может работать с таким патологическим именем. Мне удалось удалить его с помощью rm в командной строке и завершении табуляции.

    Откуда этот файл появился? Я использую файловую систему EXT4 с шифрованием LUKS на Fedora 25. Этот раздел немного старше, я создал этот 2015-окт-20 (примерно в этом месяце). О чем я должен беспокоиться?

  • Что следует учитывать при выборе файловой системы для личного дискового архива / холодного хранения?
  • Проблемы с моментальным снимком LVM
  • Symlink в тот же каталог
  • Открытый файл размера блока NFS
  • Linux эквивалент точек повторной проверки Windows?
  • Каковы плюсы и минусы двух неразрушающих тестов badblock?
  • 2 Solutions collect form web for “Странный файл с невозможным именем в моем домашнем каталоге”

    Откуда этот файл появился?

    Вы просите здесь о чистой спекуляции, но только один возможный путь – повреждение потока файловой системы или терминала.

    Примером повреждения файловой системы является то, что блок диска, где хранится имя файла, как-то поврежден, но таким образом, что все его контрольные суммы совпадают. (Без этого последнего положения файловая система просто отказалась бы восстановить поврежденные данные.) Это может произойти из-за плохой оперативной памяти, сбоя жесткого диска, изящных кабелей, космических лучей …

    Примером повреждения терминальных данных является использование последовательной линии RS-232 (или что-то, что ее эмулирует) или один из относительно толерантных протоколов, совпадающих с режимом RS-232, например Zmodem .

    Zmodem по-прежнему удобен в дни SSH и scp потому что он пробирает данные файла через соединение, которое у вас уже есть; вам не нужно каким-либо образом переключать SSH-соединение в режим SCP или устанавливать отдельное соединение SCP. Пакет lrzsz работает lrzsz SSH и Unix.

    Zmodem-over-SSH особенно удобен, когда SSH'd проходит через цепочку из двух или более хостов, но есть ловушка. Если вы используете параметры rz по умолчанию, чтобы попробовать и Zmodem двоичный файл по ссылке, вполне вероятно, что некоторая последовательность байтов в файле будет рассматриваться как escape-последовательность или управляющий символ посредником SSH-хоста, который не понимает, что это передавая передачу Zmodem, заставляя ее неверно интерпретировать поток данных, искажая передачу Zmodem. (Исправление, кстати, состоит в том, чтобы использовать rz -e для принудительного экранирования управляющих символов.)

    Когда что-то подобное происходит, текущий поток данных неверно истолковывается, поэтому внезапная передача данных может превращаться в команды в оболочку, и если что-то в этом потоке команд соответствует реальной команде (например, cat > h34ijth34u8934 ), оболочка создает файл с именем мусора. Что касается оболочки, вы попросили ее сделать это. Оболочка не знает, что источником «типизированного» имени файла является удаленная sz программа, извергающая данные файла на нем после того, как локальная программа rz которой она говорила, умерла.

    (Да, это на самом деле произошло со мной несколько раз.)

    О чем я должен беспокоиться?

    Это зависит от того, как это произошло, что снова вызывает спекуляцию.

    Это покажет вам inode файла:

     ls -lai 

    Чем вы можете его удалить:

     find . -type f -inum (inode) 

    … но я бы советовал сначала проверить, что находится в файле. Попробуйте выполнить file на нем:

    find . type f -inum (inode) -exec file {} \;

    Чем вы можете открыть его с помощью vim .

    Linux и Unix - лучшая ОС в мире.