On Fri, May 07, 2004 at 01:17:58PM +0200, JusTiCe8 wrote: > > 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.
Dans la mesure o� �a peut se faire facilement en espace utilisateur, que �a se fait d�j� de cette fa�on dans plusieurs environements (Windows, Mac, KDE, Gnome) et que personne ne s'en plaint, je vois vraiment pas l'interet de remplir le noyau de code inutile. > 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. Ben voil�, utilises KDE/Gnome/blah blah et laisse tomber rm. > 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�) Tu auras le m�me probl�me en mettant du code dans le noyau: d�cider quel fichier doit �tre vraiment effac� et quel fichier risque d'�tre re-demand� est un probl�me typique de politique d'utilisation, qui est du ressort de l'espace utilisateur. A priori, il faudrait sans doute que le nouveau syst�me d'effa�age (que ce soit en patchant rm ou en patchant unlink dans libc) utilise un fichier de configration qui lui dise quels r�pertoires contiennent des fichiers a garder (genre /home) et quels r�pertoires n'ont aucun int�r�t (genre /tmp). > C'est clair !! J'ai jamais r�ussi � obtenir de bon > r�sultats d'ailleurs avec debugfs ou recover (qui plante > parfois m�me :/) Moi si, mais �a ne change pas mon opinon :-) Y.
