impossibilite de detruire de trop nombreux fichiers
15 réponses
none
Bonsoir,
Sur une distribution CentOS 44, une aplication a genere 1 700 000
fichiers (approximativement) avant que je la stoppe.
Ces fichiers ne font que 120 octets (pas de pb d'espaces disques) chacun
porte un nom relativement long : tata_titi_XXXXXXX_XXXXXXXXXX.inf.
Le file system est LVM (par defaut a l'install)
Le souci qui se presente est l'impossibilite de detruire ces fichiers.
sous le compte root, je n'ai pas de probleme de droits mais :
la commande rm tata_titi_*.inf plante.
la commande rm trf (le repertoire de ces fichiers) semble boucler (la
taille du repertoire ne varie pas).
Un reboot de la machine n'a pas fait evoluer la situation.
Quelles possibilites ai-je pour detruire ces fichiers ?
Quelles possibilites ai-je pour detruire ces fichiers ?
rm -r -f ?
-r : détruit aussi tous les sous-répertoires -f : aucune confirmation
Olivier V
Matthieu Moy
none <""jy"@(none)"> writes:
la commande rm tata_titi_*.inf plante.
Logique : ça génère une ligne de commande de 1 700 000 arguments, et le max acceptable sous Linux doit être de l'ordre de 500 (de mémoire).
rm -fr, comme indiqué dans l'autre message, devrait faire l'affaire. Sinon, il faut un système qui appelle plusieurs fois « rm », pour un nombre de fichiers raisonnables à chaque fois. Par exemple,
Logique : ça génère une ligne de commande de 1 700 000 arguments, et
le max acceptable sous Linux doit être de l'ordre de 500 (de mémoire).
rm -fr, comme indiqué dans l'autre message, devrait faire l'affaire.
Sinon, il faut un système qui appelle plusieurs fois « rm », pour un
nombre de fichiers raisonnables à chaque fois. Par exemple,
Logique : ça génère une ligne de commande de 1 700 000 arguments, et le max acceptable sous Linux doit être de l'ordre de 500 (de mémoire).
rm -fr, comme indiqué dans l'autre message, devrait faire l'affaire. Sinon, il faut un système qui appelle plusieurs fois « rm », pour un nombre de fichiers raisonnables à chaque fois. Par exemple,
Est-ce qu'avec une boucle for du genre for FICHIER in (ls tata_titi_*.inf); do rm -rf $FICHIER; done
UUOL !
(et « $ » manquant, mais bon ;-) )
(et sinon, y'a un sigle connu pour « Useless Use Of -r ? »)
-- Matthieu
none
Matthieu Moy wrote:
none <""jy"@(none)"> writes:
la commande rm tata_titi_*.inf plante.
Logique : ça génère une ligne de commande de 1 700 000 arguments, et le max acceptable sous Linux doit être de l'ordre de 500 (de mémoire). de la a faire planter rm (segmentation) ?
sinon je suis d'accord sur la longueur (1024 non ?), mais c'est pour cela que j'avais note la 2ieme commande : rm trf (trf est le repertoire ) qui n'a rien fait (j'ai oublie le -r dans le mail sorry)
rm -fr, comme indiqué dans l'autre message, devrait faire l'affaire. Sinon, il faut un système qui appelle plusieurs fois « rm », pour un nombre de fichiers raisonnables à chaque fois. Par exemple,
je vais tente cela. Je n'y crois pas penchant plus pour une corruption... .
En tout cas grand merci a tous deux
jy
Matthieu Moy wrote:
none <""jy"@(none)"> writes:
la commande rm tata_titi_*.inf plante.
Logique : ça génère une ligne de commande de 1 700 000 arguments, et
le max acceptable sous Linux doit être de l'ordre de 500 (de mémoire).
de la a faire planter rm (segmentation) ?
sinon je suis d'accord sur la longueur (1024 non ?), mais c'est pour
cela que j'avais note la 2ieme commande : rm trf (trf est le repertoire
) qui n'a rien fait (j'ai oublie le -r dans le mail sorry)
rm -fr, comme indiqué dans l'autre message, devrait faire l'affaire.
Sinon, il faut un système qui appelle plusieurs fois « rm », pour un
nombre de fichiers raisonnables à chaque fois. Par exemple,
Logique : ça génère une ligne de commande de 1 700 000 arguments, et le max acceptable sous Linux doit être de l'ordre de 500 (de mémoire). de la a faire planter rm (segmentation) ?
sinon je suis d'accord sur la longueur (1024 non ?), mais c'est pour cela que j'avais note la 2ieme commande : rm trf (trf est le repertoire ) qui n'a rien fait (j'ai oublie le -r dans le mail sorry)
rm -fr, comme indiqué dans l'autre message, devrait faire l'affaire. Sinon, il faut un système qui appelle plusieurs fois « rm », pour un nombre de fichiers raisonnables à chaque fois. Par exemple,
je vais tente cela. Je n'y crois pas penchant plus pour une corruption... .
En tout cas grand merci a tous deux
jy
Mihamina Rakotomandimby (R12y)
none wrote:
Sur une distribution CentOS 44, une aplication a genere 1 700 000 fichiers (approximativement) avant que je la stoppe. [...]
la commande rm tata_titi_*.inf plante.
Le '*' fait qu'il remplace tata_titi_*.inf par une liste de tous les fichiers ou repertoires qui remplissent cette condition. La liste serait donc de.... 1700000 nom de fichiers. Ca fait une ligne de commande trop longue.
Est-ce qu'avec une boucle for du genre for FICHIER in (ls tata_titi_*.inf); do rm -rf $FICHIER; done ça peut fonctionner? (le 'ls' se prendrait aussi les 1700000 arguments...)
none wrote:
Sur une distribution CentOS 44, une aplication a genere 1 700 000
fichiers (approximativement) avant que je la stoppe.
[...]
la commande rm tata_titi_*.inf plante.
Le '*' fait qu'il remplace tata_titi_*.inf par une liste de tous les
fichiers ou repertoires qui remplissent cette condition.
La liste serait donc de.... 1700000 nom de fichiers.
Ca fait une ligne de commande trop longue.
Est-ce qu'avec une boucle for du genre
for FICHIER in (ls tata_titi_*.inf); do rm -rf $FICHIER; done
ça peut fonctionner? (le 'ls' se prendrait aussi les 1700000 arguments...)
Sur une distribution CentOS 44, une aplication a genere 1 700 000 fichiers (approximativement) avant que je la stoppe. [...]
la commande rm tata_titi_*.inf plante.
Le '*' fait qu'il remplace tata_titi_*.inf par une liste de tous les fichiers ou repertoires qui remplissent cette condition. La liste serait donc de.... 1700000 nom de fichiers. Ca fait une ligne de commande trop longue.
Est-ce qu'avec une boucle for du genre for FICHIER in (ls tata_titi_*.inf); do rm -rf $FICHIER; done ça peut fonctionner? (le 'ls' se prendrait aussi les 1700000 arguments...)
none
Mihamina Rakotomandimby (R12y) wrote:
none wrote:
Sur une distribution CentOS 44, une aplication a genere 1 700 000 fichiers (approximativement) avant que je la stoppe. [...]
la commande rm tata_titi_*.inf plante.
Le '*' fait qu'il remplace tata_titi_*.inf par une liste de tous les fichiers ou repertoires qui remplissent cette condition. La liste serait donc de.... 1700000 nom de fichiers. Ca fait une ligne de commande trop longue.
Est-ce qu'avec une boucle for du genre for FICHIER in (ls tata_titi_*.inf); do rm -rf $FICHIER; done ça peut fonctionner? (le 'ls' se prendrait aussi les 1700000 arguments...)
ca semble pouvoir fonctionner
for i in `ls tata*`; do ...
il me semble m'etre heurter par le passe a la limite de longueur en csh. Le bash ne semble pas poser de probleme.
merci
jy
Mihamina Rakotomandimby (R12y) wrote:
none wrote:
Sur une distribution CentOS 44, une aplication a genere 1 700 000
fichiers (approximativement) avant que je la stoppe.
[...]
la commande rm tata_titi_*.inf plante.
Le '*' fait qu'il remplace tata_titi_*.inf par une liste de tous les
fichiers ou repertoires qui remplissent cette condition.
La liste serait donc de.... 1700000 nom de fichiers.
Ca fait une ligne de commande trop longue.
Est-ce qu'avec une boucle for du genre
for FICHIER in (ls tata_titi_*.inf); do rm -rf $FICHIER; done
ça peut fonctionner? (le 'ls' se prendrait aussi les 1700000 arguments...)
ca semble pouvoir fonctionner
for i in `ls tata*`; do ...
il me semble m'etre heurter par le passe a la limite de longueur en csh.
Le bash ne semble pas poser de probleme.
Sur une distribution CentOS 44, une aplication a genere 1 700 000 fichiers (approximativement) avant que je la stoppe. [...]
la commande rm tata_titi_*.inf plante.
Le '*' fait qu'il remplace tata_titi_*.inf par une liste de tous les fichiers ou repertoires qui remplissent cette condition. La liste serait donc de.... 1700000 nom de fichiers. Ca fait une ligne de commande trop longue.
Est-ce qu'avec une boucle for du genre for FICHIER in (ls tata_titi_*.inf); do rm -rf $FICHIER; done ça peut fonctionner? (le 'ls' se prendrait aussi les 1700000 arguments...)
ca semble pouvoir fonctionner
for i in `ls tata*`; do ...
il me semble m'etre heurter par le passe a la limite de longueur en csh. Le bash ne semble pas poser de probleme.
merci
jy
Michel Tatoute
none wrote:
Bonsoir,
Sur une distribution CentOS 44, une aplication a genere 1 700 000 fichiers (approximativement) avant que je la stoppe.
Ces fichiers ne font que 120 octets (pas de pb d'espaces disques) chacun porte un nom relativement long : tata_titi_XXXXXXX_XXXXXXXXXX.inf.
Le file system est LVM (par defaut a l'install)
Le souci qui se presente est l'impossibilite de detruire ces fichiers.
sous le compte root, je n'ai pas de probleme de droits mais : la commande rm tata_titi_*.inf plante. la commande rm trf (le repertoire de ces fichiers) semble boucler (la taille du repertoire ne varie pas).
Un reboot de la machine n'a pas fait evoluer la situation.
Quelles possibilites ai-je pour detruire ces fichiers ?
Sur une distribution CentOS 44, une aplication a genere 1 700 000
fichiers (approximativement) avant que je la stoppe.
Ces fichiers ne font que 120 octets (pas de pb d'espaces disques) chacun
porte un nom relativement long : tata_titi_XXXXXXX_XXXXXXXXXX.inf.
Le file system est LVM (par defaut a l'install)
Le souci qui se presente est l'impossibilite de detruire ces fichiers.
sous le compte root, je n'ai pas de probleme de droits mais :
la commande rm tata_titi_*.inf plante.
la commande rm trf (le repertoire de ces fichiers) semble boucler (la
taille du repertoire ne varie pas).
Un reboot de la machine n'a pas fait evoluer la situation.
Quelles possibilites ai-je pour detruire ces fichiers ?
Sur une distribution CentOS 44, une aplication a genere 1 700 000 fichiers (approximativement) avant que je la stoppe.
Ces fichiers ne font que 120 octets (pas de pb d'espaces disques) chacun porte un nom relativement long : tata_titi_XXXXXXX_XXXXXXXXXX.inf.
Le file system est LVM (par defaut a l'install)
Le souci qui se presente est l'impossibilite de detruire ces fichiers.
sous le compte root, je n'ai pas de probleme de droits mais : la commande rm tata_titi_*.inf plante. la commande rm trf (le repertoire de ces fichiers) semble boucler (la taille du repertoire ne varie pas).
Un reboot de la machine n'a pas fait evoluer la situation.
Quelles possibilites ai-je pour detruire ces fichiers ?
Sur une distribution CentOS 44, une aplication a genere 1 700 000 fichiers (approximativement) avant que je la stoppe.
Wouaou!
Le souci qui se presente est l'impossibilite de detruire ces fichiers.
Je ne pense pas que ce soit impossible de les détruire, c'est juste difficile de demander aux outils de le faire.
sous le compte root, je n'ai pas de probleme de droits mais : la commande rm tata_titi_*.inf plante.
"Plante" est un terme trop vague. Dire quel est le message d'erreur exact permet à tout le monde de se pencher sur ton souci.
la commande rm trf (le repertoire de ces fichiers) semble boucler (la taille du repertoire ne varie pas).
Essaye (sans te tromper, hein, sinon ça casse tout :)
# rm -rf /chemin/vers/le/repertoire
Un reboot de la machine n'a pas fait evoluer la situation.
Sale réflexe de kroteux.
Quelles possibilites ai-je pour detruire ces fichiers ?
Bazoooookkkaaaaa ?
-- Impedance is futile, you will be simulated into the triode of the Borg. -- Robert Casey, Irish patriot
Thierry Boudet
On 2007-05-31, Matthieu Moy wrote:
(et sinon, y'a un sigle connu pour « Useless Use Of -r ? »)
Oui: "All Your Files Are Belong To Us."
-- D'un côté, les appels au bios et de l'autre, ceux au noyau Linux. Si une application a été mal portée dans Linux, il se peut qu'il reste des appels au bios, quoique ce ne soit pas très habituel sans doute. --{ DB, in fcol.configuration }--
On 2007-05-31, Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote:
(et sinon, y'a un sigle connu pour « Useless Use Of -r ? »)
Oui: "All Your Files Are Belong To Us."
--
D'un côté, les appels au bios et de l'autre, ceux au noyau Linux.
Si une application a été mal portée dans Linux, il se peut qu'il reste des
appels au bios, quoique ce ne soit pas très habituel sans doute.
--{ DB, in fcol.configuration }--
(et sinon, y'a un sigle connu pour « Useless Use Of -r ? »)
Oui: "All Your Files Are Belong To Us."
-- D'un côté, les appels au bios et de l'autre, ceux au noyau Linux. Si une application a été mal portée dans Linux, il se peut qu'il reste des appels au bios, quoique ce ne soit pas très habituel sans doute. --{ DB, in fcol.configuration }--
Fabien LE LEZ
On Thu, 31 May 2007 22:19:45 +0200, none <""jy"@(none)">:
la commande rm tata_titi_*.inf plante.
M'est avis qu'elle ne plante pas, mais qu'elle t'indique un message on ne peut plus précis, du style "argument line too long". Le couple find/xargs est ton ami.
On Thu, 31 May 2007 22:19:45 +0200, none <""jy"@(none)">:
la commande rm tata_titi_*.inf plante.
M'est avis qu'elle ne plante pas, mais qu'elle t'indique un message on
ne peut plus précis, du style "argument line too long".
Le couple find/xargs est ton ami.
On Thu, 31 May 2007 22:19:45 +0200, none <""jy"@(none)">:
la commande rm tata_titi_*.inf plante.
M'est avis qu'elle ne plante pas, mais qu'elle t'indique un message on ne peut plus précis, du style "argument line too long". Le couple find/xargs est ton ami.
