Existe-t-il un ordre d'opérations pour rm ? J'ai exécuté rm sur un grand répertoire et je suis curieux de savoir où je devrais regarder pour voir ce qui aurait pu être supprimé. Est-ce que rm travailler d'abord sur les fichiers, puis sur les répertoires ? Ou est-ce basé sur certaines informations de la table d'inodes ?
Spécifications :rm du système GNU coreutils 8.22
:Arch Linux s'exécutant sur un système de fichiers beagleboneblack
fonctionnant sur un disque dur Seagate externe (ext4) utilisant USB 2.0.
Antécédents :
J'effectuais un nettoyage de répertoire et effectué
cp -r A/ B/ C/ Dest/
Sans le vouloir, j'ai suivi cela avec
rm -r A/ B/ C/ Dest/
quand je voulais simplement jouer
rm -r A/ B/ C/
J'ai attrapé ceci et appuyé sur Ctrl +C trop longtemps ne s'était écoulé. Plus précisément, c'était <3 secondes car j'utilisais le time commande en conjonction avec rm &cp . Je suis entré et j'ai examiné Dest/ s'attendant à ce qu'il soit inexistant, mais voilà, il était entier et apparu pour ne pas être affecté. C'est un peu surprenant car A/ B/ C/ étaient assez petits. Peut-être 100 à 200 Mo au total. Dest/ cependant, est juste timide de 1 To. Exécution d'un ls sur Dest/ a montré qu'il y avait à la fois des fichiers et des répertoires aux deux extrémités de l'alphabet (par exemple AFile.txt …. …. Zoo.txt ).
Ai-je eu de la chance et annulé le rm avant qu'il ne fasse des ravages sur mon répertoire Dest/ ? Est rm vraiment si lent (heureusement !) ?
Si non, comment rm supprimer récursivement des choses de manière à ce que je puisse deviner ce qui aurait pu être perdu ?
Je ne m'attends pas vraiment à récupérer ce que j'aurais pu perdre, je suis juste curieux de savoir ce qui a potentiellement été emporté.
Réponse acceptée :
rm -r travaille tour à tour sur chacun de ses arguments. Si un argument est un répertoire, il liste le répertoire (avec le opendir et readdir fonctions ou une méthode équivalente), et opère sur chaque entrée à tour de rôle. Si une entrée est un répertoire, il explore cette entrée de manière récursive.
C'est exactement la même méthode que les autres applications utilisent pour parcourir les répertoires de manière récursive — find , ls -Rf , etc.
L'ordre de passage est imprévisible. Sur la plupart des systèmes de fichiers, l'ordre est reproductible tant qu'aucun fichier n'est ajouté, supprimé ou renommé dans le répertoire (l'ordre pourrait en théorie être complètement aléatoire et changer à chaque fois, mais je ne peux pas penser à un système de fichiers où cela se produit). Sur quelques systèmes de fichiers, l'ordre peut en général être déduit des noms de fichiers ou de l'ordre dans lequel les fichiers ont été créés ou une combinaison des deux, mais vous devez connaître les détails fins du système de fichiers, et cela peut varier selon la version du pilote. L'ordre de parcours n'est pas quelque chose sur lequel vous pouvez compter.
Connexe :Optimisation de la taille du secteur logique pour la taille du secteur physique 4096 HDD ?
Notez que ls ou echo * trier les fichiers dans l'ordre lexicographique de leurs noms. find et ls -f ne pas trier.
La seule chose sur laquelle vous pouvez compter est que les arguments sont traités dans l'ordre. Donc si C/ était encore partiellement là, cela signifierait que Dest/ était intacte. Si C/ est parti, vous pouvez avoir une idée de l'endroit où les fichiers ont été supprimés dans Dest/ en vérifiant les heures de modification du répertoire et en les comparant avec l'heure C/ a été supprimé ou l'heure à laquelle la copie s'est terminée. Le premier fichier à supprimer pourrait être un fichier directement dans Dest/ ou quelque part au plus profond de la hiérarchie selon que la première entrée dans Dest/ ce rm arrivé à traverser était un répertoire ou non.
La vitesse de rm est principalement une question de combien de fichiers il y a à supprimer. Il faut un fichier très volumineux pour avoir un impact notable sur le temps de suppression. Le gros du travail consiste à supprimer tour à tour chaque entrée du répertoire. Les données du fichier ne sont pas effacées, effacer le contenu d'un fichier nécessite seulement de marquer les blocs qu'il utilisait comme libres, ce qui est relativement rapide.