Удаление файла со странными символами в имени файла в OS X

3858
SiggyF

После ошибки памяти в моей программе я застрял в файле со странным именем файла. Это довольно устойчиво ко всем обычным методам удаления файлов со странными именами.

Имя файла:

% 8BUȅ҉% 95D% F8% FF% FF \ X0F% 8E% 8F% FD% FF% FF% 8B% B5T% F8% FF% FF% 8B% 85 \% F8% FF% FF \ x03% 85x% F8% FF% FF% 8B% 95D% F8% FF% FF% 8B% BD% 9C% F8% FF% FF% 8D \ x04% 86% 8B% B5 @% F8% FF% FF% 89% 85% 90% F8 % FF% FF% 8B% 85X% F8% FF% FF \ x03% 85% 9C% F8% FF% FF% С1% Е7 \ x02% 8B% 8Dx

Я попробовал следующее:

  • rm *
      → No such file or directory
  • rm -- filename
      → No such file or directory
  • rm "filename"
      → No such file or directory
  • ls -i чтобы получить номер инода
      → No such file or directory
  • stat filename
      → No such file or directory
  • zip каталог, в котором находится файл
      → error occurred while adding "" to the archive
  • удалить каталог в поиске
      → error -43
  • в Python: os.unlink(os.listdir(u'.')[0])
      → OSError-No such file or directory
  • find . -type f -exec rm {} \;
      → No such file or directory
  • проверил наличие блокировок на файле с lsof
      → no locks

Все эти попытки приводят к тому, что файл (длинное имя файла здесь) не найден, или ошибка -43. Даже то ls -i.

Я не мог найти больше вариантов, поэтому, прежде чем переформатировать или восстановить мою файловую систему ( fsckможет помочь), я подумал, что, возможно, что-то упустил.

Я написал эту небольшую программу на C, чтобы получить номер инода:

#include <stdio.h> #include <stddef.h> #include <sys/types.h>  int main(void)  { DIR *dp; struct dirent *ep;  dp = opendir ("./"); if (dp != NULL) { while (ep = readdir (dp)) { printf("d_ino=%ld, ", (unsigned long) ep->d_ino); printf("d_name=%s.\n", ep->d_name); } (void) closedir (dp); } else perror ("Couldn't open the directory");  return 0; }

Это работает. Теперь у меня есть номер инода, но обычный не работает. Я думаю, что я должен использовать сейчас.find -inum inode_num -exec rm '{}' \;clri

5
Зачем переформатировать? Этот файл вызывает у вас какие-либо проблемы? Где находится файл? Вы пробовали публиковать сообщения на форуме Apple? FrustratedWithFormsDesigner 14 лет назад 0
`Ls -i` перечисляет файл? Если да, но вы не можете удалить его в зависимости от inode, похоже, что файловая система повреждена. Bobby 14 лет назад 0
`Ls -i`,` ls -i filename` и `ls -i *` все выдают файл ошибки 'файл не найден'. Я переместил каталог, в котором находится файл, в корзину, но теперь непустая корзина дает мне ощущение неопрятности. Поэтому я буду продолжать пытаться убрать это. Я разместил это здесь первым. SiggyF 14 лет назад 1
Можете ли вы переименовать файл в Finder, а затем удалить? http://support.apple.com/kb/TS2039 Doug Harris 14 лет назад 0
Спасибо, да, я пытался удалить его в Finder и используя `mv`. Finder выдает ошибку -43, а mv выдает ошибку "файл не найден". SiggyF 14 лет назад 0

5 ответов на вопрос

1
bryan

Пытаться 

find . -type f -exec rm {} \;

Вы пытались удалить родительский каталог?

Спасибо за предложения. `Find` дает" Нет такого файла или каталога "в` find. -типа f`. Я попытался `rm -r` родительского и удаления каталога в Finder. Это не очистит мусор, когда я помещу этот файл в это. В нем говорится: операция не может быть завершена, потому что используется элемент «myusername». SiggyF 14 лет назад 1
есть ли шанс, что файл заблокирован открытым? Вы можете проверить с помощью lsof? bryan 14 лет назад 0
Я так не думаю. Вы имеете в виду как `mv filename / dev / null`? Я не думаю, что это работает для любого файла. SiggyF 14 лет назад 0
Файл не заблокирован. Я проверил с помощью lsof и перезагрузился. SiggyF 14 лет назад 0
1
Graham Perrin

Предполагая, что файловая система отличается от JHFS +

Симптомы могут указывать на проблему нормализации.

На форуме поддержки ZEVO NFD: normalization = formD (форма нормализации D) включает в себя частичную расшифровку стенограммы дискуссионного форума в 2012 году на Дне Illumos ZFS:

... тонкие ошибки, которые, я чувствую, никто больше не оценит мою боль. Как и в пространстве Юникода, на самом деле есть два разных способа хранения, несколько символов - как é на Mac, традиционно хранятся как символы e и ´ . Когда они оказываются, они объединяют их.

На любой другой платформе ... храните составные символы ... один клик, один символ.

Так что на Mac без вмешательства вы можете столкнуться с некоторыми неприятными проблемами, потому что Finder хранит его одним способом, а Terminal выбрал другой путь. Таким образом, вы можете зайти в Finder и создать каталог - café - затем войти в терминал и 

touch café

тогда у вас есть два объекта - у вас есть каталог и файл с абсолютно одинаковым именем, то есть он ведет ко всем видам… (!)… выглядит одинаково, но в отличие… где у вас есть дифференциатор, ничего нет, это похоже на и в Finder, в зависимости от вида Finder, вы получаете различный опыт. Иногда вы видите две папки, иногда вы видите папку и файл, иногда вы видите одну папку. Это как, это странно. Так что к сожалению ...

… Есть явная настройка formD, поэтому на Mac мы настоятельно рекомендуем, и на самом деле это по умолчанию, вы должны использовать formD, так что тогда эта проблема, вы не можете сделать это - когда вы делаете касание, оно фактически отображает его обратно на правильный путь.

Вы платите немного накладных расходов, но вы можете сохранить свое здравомыслие. Безумие иметь разные стеки, использующие разные варианты кодирования.

-  http://www.ustream.tv/recorded/25862520 около 00:10:33 на временной шкале.

1
mainzelM

Для меня

find parent-folder -delete

решил проблему. Внимание: это, конечно, удалит всю родительскую папку!

Я голосую против необъяснимого понижения голосов. Конечно, это может быть не лучшим решением, и оно может работать не во всех случаях. По этим причинам этот ответ может показаться менее полезным. Тем не менее, это новый подход, о котором кто-то может подумать не сразу, и поэтому я думаю, что это полезно рассматривать как потенциальную альтернативу. TOOGAM 9 лет назад 0
Я не понизил голос, но у меня есть проблема с этим ответом: нет логической причины, почему он должен работать, когда другие вещи были опробованы (`rm *`, удалить каталог в поиске, `find. -Type f -exec rm {} \; `, запуск` rm -r` в родительском каталоге и т. д.) не работал. Если ОП зазвонит и скажет: «Да, это сработало для меня, когда больше ничего не было!», Тогда я могу выразить это. (Но это кажется маловероятным; SiggyF, возможно, взломал файловую систему и / или выбросил компьютер за последние пять лет.)… (Продолжение) Scott 9 лет назад 0
(Продолжение)… Если mainzelM возвращается и говорит: «Я попробовал * любое другое решение *, предложенное на этой странице, и ни одно из них не сработало, и это сработало», тогда я могу начать относиться к этому серьезно. Если кто-то может объяснить, почему этот ответ должен работать, когда все остальные потерпели неудачу, я могу выразить это. В отсутствие этих вещей все, что мы знаем, это то, что у mainzelM была *** проблема *** (возможно, не совсем такая, как у ОП), которая была решена с помощью ручной гранаты (и он даже не описывает, в чем заключалась его проблема), поэтому я не считаю это хорошим ответом. Scott 9 лет назад 0
Причина, по которой `-delete` может работать в случае сбоя других подходов, заключается в том, что в этом случае имя файла не передается из одной программы в другую, а` find` удаляет сам файл, используя вызов ОС. Если вы выполните `rm *`, оболочка передаст имя файла в `rm`, и если имя файла содержит символы, которые не могут быть переданы в качестве аргумента программы,` rm` завершится ошибкой. Некоторые для `find ... -exec rm {} \;`. И да, это помогло мне в подобной ситуации. mainzelM 9 лет назад 0
1
TOOGAM

Я не мог найти больше вариантов, поэтому, прежде чем переформатировать или восстановить мою файловую систему (может помочь fsck), я подумал, что, возможно, что-то упустил.

Нет, ты был тщательным Похоже, что есть проблема с частью файловой системы. Вы могли бы это починить. Или вы можете подумать о том, что еще вы хотели бы сделать. Однако самое простое - это починить.

Возможно, вы по праву неохотно восстанавливаете файловую систему: существует очень маленький, но существующий шанс, что восстановление может произойти катастрофически. Лучший способ защитить себя от этого - создать резервную копию всех важных данных. Убедитесь, что ваши резервные копии находятся в хорошем состоянии, прежде чем восстанавливать файловую систему.

Затем начните ремонт. Когда вы знаете, что делать, иногда вам просто нужно мужество, чтобы продолжить. Вы можете обнаружить, что это полностью решено менее чем за полсекунды. (Или, может быть, немного дольше, если есть некоторые накладные расходы ... 3 секунды.)

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

Честно говоря, я не уверен, что это действительно ответ. Помимо тривиально очевидного совета сделать резервную копию всего, прежде чем делать что-либо радикальное, это не добавляет много к тому, что уже было сказано. Scott 9 лет назад 0
Основное сообщение заключается в том, что «игра с поврежденными данными также представляет возможный риск», поэтому правильный процесс должен продолжаться, а не сидеть сложа руки в надежде найти какой-то способ получить более сильное подтверждение. Основной подразумеваемый вопрос: «Каков следующий шаг?», И я даю определенный ответ вместе с причиной для этого. TOOGAM 9 лет назад 0
0
Brian Postow

Я обычно открываю вложенную папку в режиме emacs dired, а затем отмечаю и удаляю.

Спасибо за предложение. Запуск dired в этом каталоге выдает мне сообщение об ошибке: «Перечисление каталога не удалось, но« файл доступа »сработал». Я также попробовал это с aquamacs, та же ошибка. SiggyF 14 лет назад 1

Похожие вопросы