Re: fichiers effacés par accident
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.
Reply to: