"L'optimisation prématurée est la racine de tous les maux (ou du moins la plupart d'entre eux) dans la programmation." - Donald Knuth fr.wikiquote.org/wiki/Donald_Knuth
chris
Réponses:
68
Les deux sont un wrapper pour la même fonction fondamentale qui est un unlink()appel système.
Peser les différences entre les utilisations.
rm(1):
Plus d'options.
Plus de commentaires.
Vérification de la santé mentale.
Un peu plus lent pour les appels simples en raison de ce qui précède.
Peut être appelé avec plusieurs arguments en même temps.
unlink(1):
Moins de vérification de la santé mentale.
Impossible de supprimer des répertoires.
Impossible de récidiver.
Ne peut prendre qu'un argument à la fois.
Marginally plus maigre pour les appels simples en raison de sa simplicité.
Plus lent par rapport à donner rm(1)plusieurs arguments.
Vous pouvez démontrer la différence avec:
$ touch $(seq 1 100)
$ unlink $(seq 1 100)
unlink: extra operand `2'
$ touch $(seq 1 100)
$ time rm $(seq 1 100)
real 0m0.048s
user 0m0.004s
sys 0m0.008s
$ touch $(seq 1 100)
$ time for i in $(seq 1 100); do rm $i; done
real 0m0.207s
user 0m0.044s
sys 0m0.112s
$ touch $(seq 1 100)
$ time for i in $(seq 1 100); do unlink $i; done
real 0m0.167s
user 0m0.048s
sys 0m0.120s
Cependant, s’il s’agit d’un appel pur et simple à la unlink(2)fonction système , je réalise maintenant que ce n’est probablement pas ce que vous déclarez.
Vous pouvez effectuer un système unlink()sur les répertoires et les fichiers. Mais si le répertoire est un parent d’autres répertoires et fichiers, le lien vers ce parent sera supprimé, mais les enfants resteront en suspens. Ce qui est moins qu'idéal.
Modifier:
Désolé, a clarifié la différence entre unlink(1)et unlink(2). La sémantique va toujours différer d'une plate-forme à l'autre.
Cela signifie-t-il que dans les systèmes de fichiers unix, la suppression d’un répertoire et l’apparition récursive de tous les fichiers sous ce répertoire constituent toujours une opération proportionnelle au nombre de fichiers / répertoires qu’il contient? Quand se produit-il lorsque je dissocie un répertoire parent avec d'autres répertoires / fichiers? Il n'est jamais anéanti et j'ai perdu cet espace pour toujours?
Marcin
6
Il est techniquement possible de laisser des répertoires / fichiers orphelins sur la plupart des systèmes de fichiers, voire tous. Corriger cela signifie généralement exécuter un outil de réparation de système de fichiers. Sous Unix / Linux, ces outils sont appelés «fsck» et certaines variantes spécifiques pour différents systèmes de fichiers. S'ils récupèrent quelque chose, ils le laisseront normalement dans un répertoire appelé 'lost + found'
ConcernedOfTunbridgeWells
1
Correct. rm va recurse du bas de l'arbre. Vous pouvez montrer comment avec: mkdir -p 1/2/3; touch 1/one 1/2/two 1/2/3/three; rm -ri 1. Si vous avez dissocié le répertoire parent, l'espace utilisé par les enfants devrait être perdu jusqu'à ce que fsck trouve la différence.
Dan Carley
1
Qu'est-ce que tu racontes? $ mkdir -p 1/2/3 $ unlink 1 unlink: ne peut pas dissocier «1»: un répertoire qui provoque une fuite «mémoire» nécessite-t-il fsck? Peu probable!
Thomas
1
Les pages de manuel Linux et FreeBSD indiquent explicitement que cela échouera si vous essayez d’exécuter unlink () sur un répertoire.
Thomas
8
Au niveau de la spécification POSIX, ce que rm fait est spécifié beaucoup plus étroitement que ce que fait unlink .
La portabilité du résultat semble être meilleure si vous utilisez rm si votre script doit s'exécuter sur plusieurs systèmes d'exploitation.
La partie lente de la suppression concerne le code du système de fichiers et les éléments du disque, et non la préparation de l’appel système unlink () dans l’espace utilisateur.
Par exemple, si la différence de vitesse compte, vous ne devriez pas stocker les données dans le système de fichiers.
unlink est juste une entreprise "light". rm a plus de fonctionnalités mais fait la même chose.
Réponses:
Les deux sont un wrapper pour la même fonction fondamentale qui est un
unlink()appel système.Peser les différences entre les utilisations.
rm(1):unlink(1):rm(1)plusieurs arguments.Vous pouvez démontrer la différence avec:
Cependant, s’il s’agit d’un appel pur et simple à la
unlink(2)fonction système , je réalise maintenant que ce n’est probablement pas ce que vous déclarez.Vous pouvez effectuer un système
unlink()sur les répertoires et les fichiers. Mais si le répertoire est un parent d’autres répertoires et fichiers, le lien vers ce parent sera supprimé, mais les enfants resteront en suspens. Ce qui est moins qu'idéal.Modifier:
Désolé, a clarifié la différence entre
unlink(1)etunlink(2). La sémantique va toujours différer d'une plate-forme à l'autre.la source
mkdir -p 1/2/3; touch 1/one 1/2/two 1/2/3/three; rm -ri 1. Si vous avez dissocié le répertoire parent, l'espace utilisé par les enfants devrait être perdu jusqu'à ce que fsck trouve la différence.Au niveau de la spécification POSIX, ce que rm fait est spécifié beaucoup plus étroitement que ce que fait unlink .
La portabilité du résultat semble être meilleure si vous utilisez rm si votre script doit s'exécuter sur plusieurs systèmes d'exploitation.
la source
La partie lente de la suppression concerne le code du système de fichiers et les éléments du disque, et non la préparation de l’appel système unlink () dans l’espace utilisateur.
Par exemple, si la différence de vitesse compte, vous ne devriez pas stocker les données dans le système de fichiers.
unlink est juste une entreprise "light". rm a plus de fonctionnalités mais fait la même chose.
la source