J'ai créé un fichier par accident avec un nom de fichier de (NUL).xml sauf qu'au lieu de (NUL) c'est littéralement '\0' . Aucune des méthodes que j'ai essayées n'a permis de le supprimer. Existe-t-il un moyen de supprimer le fichier par une autre référence ?
Ok, je ne peux pas tester ceci (pour des raisons, je l'espère, évidentes), mais si les noms de fichiers sont votre problème... utilisez inode s !
Tout d'abord, dans un répertoire, exécutez ls -il (-i est montrer les numéros de nœuds et -l pour en faire une liste) :
2480878 -rw-r--r-- 1 christopher family 0 Mar 2 19:40 *a
2480889 -rw-r--r-- 1 christopher family 0 Mar 2 19:40 \\a
2480873 -rw-r--r-- 1 christopher family 0 Mar 2 19:39 aDans cet exemple, je vais effacer le fichier \\a qui est l'inode 2480889 .
Donc je cours find . -inum 2480889 -delete .
J'espère que ça va marcher.
LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.
0 votes
Je l'ai créé avec une ancienne version de Java qui me permettait de créer des fichiers avec un octet nul dans le nom du fichier par accident. Malheureusement, j'ai mis à jour depuis longtemps et clri n'est pas disponible sur El Capitan, donc je ne peux même pas effacer l'inode.
0 votes
J'ai essayé ça et bien d'autres choses encore. Ça ne marche pas.
0 votes
J'espère plus ou moins que quelqu'un a une méthode pour effacer les inodes sur El Capitan.
0 votes
Le problème est qu'il tente de supprimer le fichier en utilisant le nom du fichier, ce qui est exactement le problème. L'octet nul fait trébucher RM.
0 votes
Ouais. Cela pose le même problème que d'invoquer l'appel unlink() contre le nom du fichier.
0 votes
Je l'ai essayé avec
clri /dev/disk0s2 -inode(à partir d'une installation 10.6 copiée sur un système 10.9) et en manipulant directement le fichier catalogue avec un éditeur hexagonal. Rien ne fonctionne ou bien le disque est complètement corrompu (dans ce dernier cas).0 votes
Par "corrompt complètement le disque", voulez-vous dire qu'il faut faire un fsck ? Parce que c'est un comportement connu et attendu avec Clri.
0 votes
Clri ne fonctionne tout simplement pas avec le message (d'erreur ?) suivant :
clri: /dev/disk0s2: superblock magic number 0x0, not 0x11954. La manipulation directe du fichier catalogue du système de fichiers avec un éditeur hexagonal corrompt complètement le volume et il est impossible de le récupérer bien que je n'aie modifié que 4 octets.0 votes
Est-ce le seul fichier d'un répertoire ? Ou est-ce le seul fichier avec une certaine extension ? Vous pouvez alors essayer d'utiliser
rmavec un caractère générique à la place du caractère en question ou supprimer le répertoire entier (rm -rf ./THEDIRECTORY) ? Ou vous pourriez regarder unix.stackexchange.com/questions/28983/ qui pourrait aussi aider. Je cherche généralement des réponses linux dans ces cas-là. Autre solution : installer midnight commander - cela fonctionne généralement dans ces cas.