Forum

Bonjour

Je constate depuis quelques jours (mais je ne me souviens pas de quand cela a commencé...) qu'il faut beaucoup de temps (quelques secondes) pour déplacer un fichier vers la poubelle depuis Dolphin.
Même un petit fichier texte prend du temps. Alors que la copie d'un fichier, même un peu gros, est quasi-instantanée.
Je ne vois rien dans le journalctl.

Vous avez déjà été confronté à cela ?

Merci

A+

Bonjour

Perso j'ai resolu le probleme (et du coup pas mal d'autres)

dans /home/[...]/.local/share/kservices5/ServiceMenus/
J'ai creer un fichier appelé : renw&kill.desktop

dans ce fichier, j'y ai mis ceci :

[Desktop Action actions]
Exec=mv %U FichDEAD.000 && shred -n 35 -z -u FichDEAD.000
Icon=user-busy
Name[fr_FR]=DESTROY
Name=DESTROY

[Desktop Entry]
Actions=actions;
Icon=user-busy
MimeType=image/jpeg;image/png
ServiceTypes=KonqPopupMenu/Plugin,all/allfiles
Type=Service
X-KDE-Priority=TopLevel
X-KDE-Submenu=DANGER : Detructions DEFINITIVE
X-KDE-StartupNotify=false

Un simple clic droit est bonsoir le fichier...
"Definitivement" (DONC ! ATTENTION !)

petite precisions importantes :
- shred sur ssd ne sert a rien :(
- Pas obligé de mettre 35 dans shred...

j'en ai fait un autre pour wipe (sous rep)

voilà si ca peu aider.....

Est-ce lié aux partitions ?
Dans quelle partition est la corbeille ? Dans quelle partition était le fichier à l'origine ?

Un déplacement d'un fichier à l'intérieur d'une partition : on ne fait que réécrire le lien, le fichier reste à l'adresse [partition1+0x32244] et le lien pointant dessus, au lieu d'être /partition1/sous-dossier/fichier1 sera /partition1/poubelle/fichier2
Un déplacement d'une partition à une autre : on recopie le fichier de [partition1+0x32244] à [partition2+0x032984] puis on supprime le fichier /partition1/sous-dossier/fichier1 et on créer le fichier /partition2/poubelle/fichier2

Je trouve que c'est une solution "lourde", alors que la combinaison de touche [SHIFT]+[SUPPR] supprime définitivement le fichier (sans passer par la corbeille), ça a presque le même effet que ce script (avec shred en moins). Son plus : c'est valable partout, c'est un standard presque. Même sous windows.

exact jybz, bonjour a toi

Mais deux choses (en + ?)
Un fichier passé par [SHIFT]+[SUPP]
peu, malheureusement, être "reactivé" par des choses, style "photorec" et autres joyeuseté (j'en ai fais les frais...)

C'est d'ailleur pour ca, que j'ai crée renw&kill.desktop

1 - il renomme tout les fichiers sous le même nom : mv %U FichDEAD.000
En cas de tentative de "recup" ,il n'y aurais que le dernier FichDEAD.000 (et encore... en mauvais état...)
2 - il shred (ou wipe) ce fichier FichDEAD.000 35 fois...
On peu penser qu'au bout de 35 fois, il n'en reste pas grand choses

Oui, je sais c'est mon coté parano (mais comme dis Mishkine, Weiss, Snowden :"Il vaut mieux un fichier ecrasé par un autre qu'un delete qui ...")
Alors moi, j'ecrase le fichier avec FichDEAD.000 puis shred 35 fois...
comme cà ! a pu le fichier

Bonjour,
J'ai en effet déjà constaté ce genre de souci (Mageia 7). Je ne sais pas à quoi c'est dû. Ceci peut se passer sur la même partition. La piste de jybz ne me semble pas la bonne, même si elle mérite d'être évoquée.
Précision. C'est sur une partition chiffrée en Luks.

Édité par Papoteur Le 22/04/2021 à 11h19

35 passages ? Inutile ?
renommer ne change rien, les données restent à la même adresse du disque. photorec, s'il récupère des fichiers hors table des fichiers, il ne connait pas le nom, donc le renommer ne change rien. Puis, si le fichier supprimé est suivit d'un "shred" (je ne sais pas à quoi ça sert, et ça ne m'intéresse pas pour l'instant) dans le but d'être sûr de ne pas les récupérer, le mieux est d'écraser ce fichier, par exemple avec `dd if=/dev/zeros of=/chemin/fichier bs=1 count=$(taille de fichier en octet) ` ainsi les données sont supprimées, puis le supprimer simplement : rm /chemin/fichier.

Bonjour

Tout se passe sur la même partition et même disque SSD ; a priori et je vais regarder cela de plus prêt.
Est-ce que le .trash aurait changé de place ???

Edit : euh, il devrait se trouver où normalement le .trash ? Je ne le trouve pas....

A+

Édité par squid-f Le 22/04/2021 à 12h04

completement d'accord avec toi jybz

(Mais dd me fait un peu peur :s (il a la renommé (vrais ou pas ??? ca j'ignore (mais je veux pas prendre le risque...), dd a la renommé d'être (je cite) : "un tueur de disk")
En tout cas c'est la reputation qu'il a a travers pas mal de sites...

* c'est vrais que s'il n'avais pas cette réputation, je l'utiliserais direct moi

enfin, moi, ce que j'en disais...

Édité par steven Le 22/04/2021 à 12h06

Bon

j'ai trouvé ~/.local/share/Trash/files

Ce qui est étrange, c'est que j'ai plus de fichiers que dans ma corbeille quand j'y vais via Dolphin.

ls -al done :


mais, via Dolphin, dans le dossier Corbeille, je n'ai que les 2 firefox.....rpm

J'ai donc effacé en console les 2 répertoires fantômes et la mise à la poubelle est maintenant instantanée

Merci pour vos pistes !

A+

G (M) Steven. Pour être honnête, il me semble ... Ce que vous faites est un travail inutile ... Ne vous offusquez pas. Pourquoi avez-vous besoin de quelque chose de plus que Shift+Del? De plus, les logs sont stockés à de nombreux endroits (cache, historique). Craignez-vous qu'un étranger ait un accès physique à votre ordinateur? Dans ce cas, je peux te comprendre.

Bonjour papoteur

En fait, en y réfléchissant, j'ai eu des problèmes de poubelle pleine et qui ont nécessités de vider manuellement celle-ci.
Je pense que cela coïncide avec le début des lenteurs constatées.
Peut-être que KDE s'est mélangé les pinceaux à ce moment là ?

A+