bash - répertoires se terminant par. et les espaces ne peuvent pas être supprimés

0

Sur mon disque dur externe se trouvent deux répertoires, Fun. et Complex_, où cela _ est un espace. Je ne peux pas vider mes ordures ni les enlever avec rm -rf et je veux. Ni apparaissent dans Finder sur OSX, et je ne me souviens pas si elles sont apparues dans Dolphin sous Linux. Mais ils apparaissent dans Bash.

rm et mv résultats No such file or directory. Les dossiers contenant peuvent être déplacés et apporter les répertoires spéciaux avec eux, mais ils ne peuvent pas être supprimés.

Pourquoi peut ls détecter les fichiers mais rm et mv ne peut pas Comment puis-je les réparer? j'utilise \_ sur le fichier complexe. (_ est un espace).

modifier

Les personnages ne doivent pas être le problème. J'ai fait "test". et "test" et je n'ai eu aucun mal à les supprimer en utilisant des guillemets. Mais ces fichiers ne peuvent toujours pas être supprimés. Il doit y avoir quelque chose de très bas avec un problème avec les fichiers eux-mêmes

sagan:Math ptwales$ ls
Complex 
sagan:Math ptwales$ ls -i
ls: Complex : No such file or directory
sagan:Math ptwales$ ls -idF *
ls: Complex : No such file or directory
sagan:Math ptwales$ find . -name * -print0
find: ./Complex : No such file or directory
sagan:Math ptwales$ 

Même résultat avec Fun. Je devine que les répertoires parents ont des liens vers les fichiers et connaissent leur nom, mais les fichiers n'existent tout simplement pas ou sont corrompus d'une manière ou d'une autre.

Le lecteur externe est au format exFAT. Cela serait-il pertinent?

cheezsteak
la source
Cela ressemble à un système de fichiers corrompu ou à une implémentation avec un système de fichiers défectueux. Vous avez tagué la question osx, linux et unix. Sur quels systèmes avez-vous essayé d'accéder aux fichiers? Les résultats étaient-ils différents? Avez-vous essayé d'accéder aux fichiers sous Windows avec le support exFAT (voir ma réponse partielle)?
pabouk
J'ai créé les fichiers sur Linux sur une partition ext4, puis les ai sauvegardés sur exFAT. Je me souviens avoir eu ce problème en le supprimant sur le système ext4, mais je ne peux pas vérifier. Les fichiers ne sont pas là maintenant parce que j'ai repartitionné ce disque depuis. À l'heure actuelle, il est accessible depuis OSX. Je peux essayer à partir de la configuration de Windows d'un ami ou démarrer à partir d'une clé USB debian, mais le support exFat n'est peut-être pas installé sur le liveISO.
cheezsteak
"Le disque externe est au format exFAT. Cela serait-il pertinent?" Je dirais que c'est tout à fait possible, car la famille de systèmes de fichiers FAT traite les noms de fichiers très différemment des systèmes de fichiers normalement utilisés sur les systèmes de type Unix.
a CVn

Réponses:

5

rm et mv peuvent aussi bien détecter les répertoires, mais vous tapez: rm file alors le shell ignorera les espaces.

Vous pouvez faire quelque chose pour contourner ce problème. Le plus simple est d'encapsuler le nom du fichier. Une autre solution consiste à échapper le caractère spécial, par exemple avec une barre oblique inverse

Exemple:

touch "testfile "

host:/home/username/test>ls -al
total 12
drwx------   2 hennes  users  4096 Sep 26 02:44 .
drwxr-xr-x  34 hennes  users  8192 Sep 26 01:39 ..
-rw-------   1 hennes  users     0 Sep 26 02:44 testfile

Maintenant, pour les supprimer, soit:

rm "testfile ", ou

rm testfile\ (s'il vous plaît noter les espaces après la barre oblique inverse)


Quant aux noms de fichiers se terminant par un point. Je ne peux pas reproduire le problème. Êtes-vous sûr que cela se termine par un point et non par un autre caractère spécial?

toad:/home/hennes/test>bash --version
GNU bash, version 4.1.10(1)-release (amd64-portbld-freebsd7.3)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

toad:/home/hennes/test>touch Fun.

toad:/home/hennes/test>ls
Fun.

toad:/home/hennes/test>rm Fun.
toad:/home/hennes/test>ls
toad:/home/hennes/test>

S'il s'agit d'un autre caractère qu'un point, lisez le Séparateur de fichiers interne en bash. Vous pouvez le définir sur autre chose ou simplement utiliser des commandes telles que find with -print0. (Exemple find /path/to/search-name 'SomeFilePattern*' -print0 | some_command )

Hennes
la source
Cela fonctionne avec d'autres répertoires de test mais pas avec ceux-là. Les caractères de fin ne doivent pas être le problème ici.
cheezsteak
Est-ce que ls -B montrer quelque chose? (-B Forcer l’impression des caractères non imprimables (définis par ctype (3) et les paramètres régionaux en vigueur) dans les noms de fichiers sous la forme \ xxx, où xxx est la valeur numérique du caractère en octal.)
Hennes
ls -B "Complex " et Fun. les deux ne donnent pas un tel fichier ou répertoire. Je me dirige vers cela, il doit y avoir une corruption de fichier exFAT peut-être causée par les noms de fichiers, mais les noms de fichiers ne sont pas le problème maintenant.
cheezsteak
1

J'ai écrit une réponse à ce sujet à une question assez similaire sur faute de serveur. Le principe est légèrement différent mais la réponse est généralement identique.

Vous pouvez combiner ls -i (ou stat qui imprime également le numéro d’inode) et find -inum. Cela fonctionne bien pour un petit nombre de fichiers où, pour une raison quelconque, la suppression directe par un caractère générique n'est pas souhaitée. L'exemple ci-dessous est adapté aux répertoires, alors que la réponse sur Server Fault traite des fichiers, mais le principe est le même: utiliser le numéro d'inode pour identifier l'entrée de répertoire avec laquelle faire quelque chose.

Par exemple:

~$ ls -idF myweirddir
183435818 myweirddir/
~$ find . -inum 183435818 -exec mv -v '{}' 'delete-me' ';'
`./myweirddir' -> `./delete-me'
~$ ls -lA delete-me/
... check the contents ...
~$ rm -rf delete-me
~$

Cette réponse est également terminée sur Server Fault, avec des différences mineures et une variante de remplacement avec substitution directe de processus à l'aide de find et stat, ce qui n'est probablement pas vraiment applicable dans votre cas. Si vous aimez la réponse ici, envisagez également le vote positif sur Server Fault.

a CVn
la source
Je ne peux pas obtenir le numéro d'inode des fichiers. Peut-être que les fichiers n’existent pas et que le problème vient du répertoire parent qui pense le faire?
cheezsteak
1

Cela ressemble à un système de fichiers corrompu ou à une implémentation avec un système de fichiers défectueux.

Malheureusement le exFAT Le système de fichiers est mal pris en charge sur les systèmes non-Microsoft. Si vous avez la possibilité d’utiliser un système de fichiers différent, considérez-le.

Veuillez vérifier l'intégrité du système de fichiers. Sous Linux, vous pouvez vérifier l’intégrité exFAT en exécutant exfatfsck. Malheureusement, cet utilitaire ne pourra pas réparer le système de fichiers. Sous Windows (XP avec mise à jour KB955704, Vista SP1 ou plus récent), vous pouvez utiliser chkdsk qui est capable à la fois de vérifier et de réparer le système de fichiers.

pabouk
la source
-1

Quand il y a un fichier avec un nom étrange que vous ne pouvez pas taper, vous pouvez utiliser la fonction bash select:

select f in * .*; do rm -i $f; done
dnt
la source
2
Si vous ne citez pas $f, cela ne fonctionnera pas avec toutes sortes de noms de fichiers.
slhck
(1) Cela posera des questions sur chaque fichier du répertoire, ce qui peut être ou ne pas être ce que veut le PO. (2) rm -i ne fonctionne pas sur les répertoires, ce que le PO demande spécifiquement. (3) Comme @slhck dit, citant de $f, notamment considérant que le problème même du PO réside dans les noms exotiques.
a CVn