Bonjour,
Yves Rutschle wrote:
On Fri, May 07, 2004 at 08:17:21AM +0200, Fran�ois Boisson wrote:
Quel est l'int�r�t d'avoir fait �a??? C'est � mon avis un s�rieux b�mol
pour ext3...
Bof; ext2 n'est pas r�ellement utilisable pour les disques
"modernes" (� plus de 100Go, m�me si Linux est en g�n�ral
tr�s stable, je suis pas pr�s � risquer 10 heures de fsck
quand ext3 le fera en 5 secondes), et il est de toute fa�on
facile d'argumenter que ce genre de chose n'est pas une
fonction du fs ou du noyau.
Ca c'est certain. Mais rien n'emp�che d'inclure ce genre de chose, au
moins sous forme de patchs optionels.
On remarquera d'ailleurs que la plupart des autres OS ne
permettent pas �a non plus. Le probl�me ici est que l'on
s'est habitu� aux interfaces "Finder Mac" qui n'effacent pas
r�ellement les fichiers, et que maintenant on s'attend aux
m�me fonctionalit�s de la part des vieilles commandes de
bases telles que /bin/rm.
Certe, mais le progr�s, c'est aussi de prendre le meilleur partout o� il
se trouve. M�me sur le syst�me le plus m�diocre, il y a une chance de
trouver un truc int�r�ssant et innovant.
Puis pourquoi se rattacher � une commande datant de la pr�histoire et en
rester l� ?
Faisons �voluer aussi les commandes de bases plut�t que de tjs penser au
noyau et consorts.
Comme sugg�r� ailleurs, la solution la plus simple est de
changer /bin/rm, ou mieux de patcher unlink(2) et rmdir(2)
dans la libc pour les faire d�placer les fichiers.
le patch n'est pas une bonne id�e � mon humble avis (m�me si c 'est la
plus "system-wide" qui soit mais si un programme vire un fichier
temporaire, l'utilit� de voir ce dernier dans une poubelle quelquepart
est tr�s limit�)
Aller pecher des inodes d�saffect�s directement sur un block
device est de toute fa�on tellement �videment Mal que �a ne
peut �tre que la pire solution.
C'est clair !! J'ai jamais r�ussi � obtenir de bon r�sultats d'ailleurs
avec debugfs ou recover (qui plante parfois m�me :/)
Y.
A+,
J8.
