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

Question

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

Имя файла:

% 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 сейчас.

Answer 1

Для меня

find parent-folder -delete

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

Answer 2

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

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

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

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

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

Answer 3

Пытаться

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

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

Answer 4

Предполагая, что файловая система отличается от 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 на временной шкале.

Answer 5

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