Как удалить этот неудаляемый каталог?
Доберитесь до оболочки (начальная загрузка в спасение / однопользовательский режим в случае необходимости) и просто mount -o remount,rw /.
Или если Вы загружаетесь от спасательного CD, затем он ничего не знает о/etc/fstab, поэтому просто не указывайте -o discard при монтировании.
Следующий отрывок из этого эссе потенциально объясняет, почему этот каталог отказывается удалять:
NFSv4 требует, чтобы все имена файлов обменивались с использованием UTF-8 по сети. Спецификация NFSv4, RFC 3530, говорит, что имена файлов должны быть в кодировке UTF-8 в разделе 1.4.3: «В небольшом отступлении, имена файлов и каталогов кодируются в UTF-8, чтобы иметь дело с основами интернационализации». Тот же текст также находится в новом NFS 4.1 RFC (RFC 5661), раздел 1.7.3. Текущий клиент Linux NFS просто передает имена файлов напрямую, без какого-либо преобразования из текущей локали в UTF-8 и обратно. Использование имен файлов, отличных от UTF-8, может стать реальной проблемой в системе, использующей удаленную систему NFSv4; любой сервер NFS, который следует спецификации NFS, должен отклонять имена файлов, отличных от UTF-8. Поэтому, если вы хотите убедиться, что ваши файлы действительно могут храниться с клиента Linux на сервере NFS, в настоящее время вы должны использовать имена файлов UTF-8. Другими словами, хотя некоторые люди думают, что Linux не навязывает конкретную кодировку символов для имен файлов, на практике в некоторых случаях уже требуется кодировка UTF-8 для имен файлов.
UTF-8 - это более долгосрочный подход. Системы должны поддерживать UTF-8, а также многие старые кодировки, чтобы у людей было время переключиться на UTF-8. Чтобы использовать «UTF-8 везде», все инструменты должны быть обновлены для поддержки UTF-8. Несколько лет назад это было большой проблемой, но по состоянию на 2011 год это, по сути, решенная проблема, и я думаю, что траектория для этих нескольких трейлинговых систем очень ясна.
Не все последовательности байтов допустимы для UTF-8, и вам не нужно придумывать, как их отображать. Если ядро применяет эти ограничения, гарантируя, что разрешены только имена файлов UTF-8, тогда нет проблем ... все имена файлов будут допустимыми UTF-8. Функция UTF8_check C Маркуса Куна может быстро определить, является ли последовательность допустимой для UTF-8.
Файловая система должна требовать, чтобы имена файлов соответствовали некоторому стандарту, не из-за какой-то злой потребности контролировать людей, а просто для того, чтобы имена всегда могли отображаться правильно в более позднее время. Отсутствие стандартов усложняет задачу пользователям, а не облегчает их работу. Тем не менее, файловая система не заставляет имена файлов быть UTF-8, поэтому в ней легко может быть мусор.
Пытались ли вы использовать rm -rf ./mikeaâcnt или rm -rf "./mikeaâcnt" или абсолютный путь? Также вместо rm попробуйте rmdir ./mikeaâcnt.
Одним из способов удаления таких файлов/директорий является использование их кодовых ссылок.
Найти коды для элементов в текущем dir:
ls -i
14813568 mikeaâcnt
Удалить это:
find . -inum 14813568 -delete
Я лично протестировал, используя директиву find's -exec:
$ mkdir -p mikeaâcnt
$ ls
mikeaâcnt
$ find -maxdepth 1 -type d -empty -exec rm -rf {} +
$ ls
$
Папка была правильно создана и правильно удалена.
Как указывает @Igeorget, есть еще более простой метод, если у вас есть GNU find:
$ find -maxdepth 1 -type d -empty -delete
Я также тестировал эту команду, и она корректно работает
.Вы не должны использовать символы, отличные от ASCII, в командной строке, поскольку, как вы могли видеть, по какой-то причине они не обязательно соответствуют имени файла (Unicode имеет различные способы выражения букв с диакритическими знаками). Что-то вроде:
rm -rf mike*
должно работать, поскольку имя файла создается непосредственно оболочкой. Но убедитесь, что есть только одно совпадение (сначала сделайте эхо-микрофон * для подтверждения).
Что ж, если cd работает, то нет причин, по которым rm или ls должны сказать Нет такого файла или каталога , поэтому что проблема может быть на уровне файловой системы.
Примечание: не используйте ls , чтобы узнать, пуст ли каталог, а используйте ls -a .
Каталог все еще может использоваться другим процессом (в том числе, если это cwd какого-либо процесса). ИМХО, поэтому он до сих пор «существует», но может давать ошибки, например с LS ; lsof может дать вам некоторую информацию, но с NFS вам нужно найти, какая машина его использует. Это может приводить к странным ошибкам, особенно с NFS. ls -a в родительском каталоге может в некоторых случаях показать вам .nfs * файлы / каталоги.
Когда вы получите:
$ ls
ls: cannot access mikeaâcnt: No such file or directory
mikeaâ??cnt
Я подозреваю, что файл все еще существует в таблице каталогов из-за кэширования NFS и / или из-за того, что он используется другим процессом, но без связанной информации. Когда ls пытается получить информацию о самом файле, он получает ошибку, поскольку сам файл больше не существует (он находится только в таблице каталогов), следовательно, отображается ошибка. Затем ls выводит имя файла, потому что оно находится в таблице каталогов. Тот факт, что у вас есть вопросительные знаки в одном случае, но не в другом, связан с ошибкой отображения ls ИМХО (не имеющей отношения к вашей проблеме).
После получения правильного шестнадцатеричного кода имени файла/папки (используя любой метод, который сочтете нужным, я могу выбрать ls - show-control-chars | xxd), для обращения к таким символам при выполнении под bash:
rmdir $'mikea\xc3\xa2\xc2\x81\xc2\x84cnt'
Иначе обратные слеши будут рассматриваться как ванильный обратный слеш.
У меня были похожие проблемы. У Вас есть Gnome, KDE или какой-нибудь Xwindow DM? Если Вы откроете свой файловый браузер и удалите файл оттуда.
Это должно сработать.
Я хотел бы увидеть решение из командной строки, но в моем случае и после того, как я потерял много времени, пытаясь понять, как удалить его из командной строки, я обнаружил, что это так же просто, как удалить любой другой файл из nautilus или любого другого проводника файлов (правда в том, что я пытался только с помощью nautilus).
Одним из способов решения этой проблемы является использование systemd-networkd. Набор конфигурационный файл по адресу /etc/systemd/network/net0dhcp.network (или аналогичный):
[Match]
Name=net0
[Network]
DHCP=true
Переименовать net0 в приведенном выше имени сетевого интерфейса. Теперь:
systemctl disable dhcpcd
systemctl enable systemd-networkd
И перезагрузка. (Вероятно, некоторые службы можно перезапустить; Я не нашел, какая перезагрузка была достаточно быстрой).
Я протестировал это только с проводной сетью (и у меня нет машины с беспроводной картой, лежащей вокруг в данный момент), поэтому я не могу комментировать, как эта конфигурация будет работать с вашим беспроводным интерфейсом. Я предполагаю, что вам нужно будет добавить файл конфигурации для этого интерфейса, и все будет круто. Конечно, если не получается так просто, всегда можно просто:
systemctl disable systemd-networkd
systemctl enable dhcpcd
И перезапустить.
Дополнительная информация: https://wiki.archlinux.org/index.php/Systemd-networkd#Basic_DHCP_network
-121--114840-Это поведение звучит необычно и может указывать на аппаратную проблему. Проблема может быть такой же простой, как свободный кабель, или неисправным жестким диском.
Вы можете рассмотреть статистику дисков с помощью такого инструмента, как gsmartcontrol . Обратите внимание, что необходимо запустить приложение от имени root, чтобы оно имело полный доступ к жесткому диску.
-121--116515- Пытались ли вы получить inode этого файла с помощью stat :
stat mike*
Это должно дать вам номер inode (и другие данные), а затем вы можете попытаться удалить его.
У меня была такая же проблема. Я видел эту проблему ранее с именем файла ☃. ls в этом случае отобразил файл как â?, но я смог удалить его с помощью rm ☃.
Это привело меня к следующему способу преобразования неправильного имени в правильное:
Сначала получите байты имени файла:
$ ls --show-control-chars | xxd
0000000: 6d69 6b65 61c3 a2c2 81c2 8463 6e74 0a mikea......cnt.
Затем декодируйте эти байты как UTF-8, чтобы получить кодовые точки юникода, используя шестнадцатеричный вход этого сайта, например: http://software.hixie.ch/utilities/cgi/unicode-decoder/utf8-decoder
U+006D LATIN SMALL LETTER M character
U+0069 LATIN SMALL LETTER I character
U+006B LATIN SMALL LETTER K character
U+0065 LATIN SMALL LETTER E character
U+0061 LATIN SMALL LETTER A character
U+00E2 LATIN SMALL LETTER A WITH CIRCUMFLEX character (â)
U+0081 <control> character ()
U+0084 <control> character („)
U+0063 LATIN SMALL LETTER C character
U+006E LATIN SMALL LETTER N character
U+0074 LATIN SMALL LETTER T character
Обратите внимание, что все они находятся ниже границы байта. Мы получаем следующие байты:
6D 69 6B 65 61 E2 81 84 63 6E 74
Если мы обработаем эту последовательность в UTF-8, то получим:
U+006D LATIN SMALL LETTER M character
U+0069 LATIN SMALL LETTER I character
U+006B LATIN SMALL LETTER K character
U+0065 LATIN SMALL LETTER E character
U+0061 LATIN SMALL LETTER A character
U+2044 FRACTION SLASH character (⁄)
U+0063 LATIN SMALL LETTER C character
U+006E LATIN SMALL LETTER N character
U+0074 LATIN SMALL LETTER T character
И таким образом, ваше имя файла будет: mikea⁄cnt, с дробной косой чертой вместо обычной прямой. Теперь вы можете передать это имя в rmdir.