Bonjour, Yves Rutschle wrote:
Ca c'est certain. Mais rien n'empêche d'inclure ce genre de chose, au moins sous forme de patchs optionels.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 unefonction du fs ou du noyau.
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.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.
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é)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.
C'est clair !! J'ai jamais réussi à obtenir de bon résultats d'ailleurs avec debugfs ou recover (qui plante parfois même :/)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.
Y.
A+, J8.