DÉFRAGMENTER UN FICHIER
violent_ken
Messages postés
1812
Date d'inscription
mardi 31 mai 2005
Statut
Membre
Dernière intervention
26 octobre 2010
-
4 déc. 2006 à 19:27
MadM@tt Messages postés 2167 Date d'inscription mardi 11 novembre 2003 Statut Membre Dernière intervention 16 juillet 2009 - 15 avril 2007 à 02:00
MadM@tt Messages postés 2167 Date d'inscription mardi 11 novembre 2003 Statut Membre Dernière intervention 16 juillet 2009 - 15 avril 2007 à 02:00
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/40578-defragmenter-un-fichier
https://codes-sources.commentcamarche.net/source/40578-defragmenter-un-fichier
15 avril 2007 à 02:00
Je tombe sur ça que maintenant, félicitations, comme toujours ^^
19 févr. 2007 à 23:14
@+
12 janv. 2007 à 21:42
Merci bien
A +
12 janv. 2007 à 21:21
ShareVB
7 janv. 2007 à 21:14
Oublies les posts précédents pour la cartographie correcte des clusters
Il suffit simplement de mettre dans le module modVolume au niveau de la fonction GetVolumeBitmap(Volume As String, VolumeSize As Long) As VolumeFreeClusters() la ligne suivante juste avant la boucle Do .... Loop
Volumesize = 0
La première cartographie au lancement du logiciel était poujours correcte mais les suivantes demandées par le contrôle Drivelistbox étaient incorrectes car Volumesize n'était pas modifié vu que sa valeur était différente de 0 : donc le if Volumesize = 0 ne se faisait jamais pour le Then qui le suit et Volumesize restait toujours à la même valeur quelle que soit la partition analysée.
Ce fut un bug très intéressant à trouver j'avoue
A+ et meilleurs voeux pour 2007
7 janv. 2007 à 18:02
7 janv. 2007 à 18:01
Pour la cartographie correcte des clusters j'ai trouvé ( enfin je pense)
Dans le module ModVolume et dans la fonction GetVolumeBitmap il faut ajouter
1° dans les déclarations en début de procédure : Dim Sectorsperclusters As Long, Bytespersector As Long, Freeclusters As Long, Totalclusters As Long
Dim func as long
2° A la place de la ligne de code "If VolumeSize = 0 then .....etc
il faut mettre la ligne suivante
func = GetDiskFreeSpace(Volume, Sectorsperclusters, Bytespersector, Freeclusters, Totalclusters)
VolumeSize = Totalclusters
3) Ajouter la déclaration suivante en début de procédure
Private Declare Function GetDiskFreeSpace Lib "kernel32.dll" Alias "GetDiskFreeSpaceA" (ByVal lpRootPathName As String, ByRef lpSectorsPerCluster As Long, ByRef lpBytesPerSector As Long, ByRef lpNumberOfFreeClusters As Long, ByRef lpTtoalNumberOfClusters As Long) As Long
Ainsi la cartographie des clusters est toujours correcte
A+
7 janv. 2007 à 13:35
Cette ligne dans la Function GetVolumeBitmap(Volume As String, VolumeSize As Long) As VolumeFreeClusters()
"If VolumeSize 0 Then VolumeSize VolumeBitmap.BitmapSize.LowDWORD" devrait donner le nombre total de clusters du volume mais donne un résultat erronné : donne 20679663 pour un volume de 4887768 clusters
De plus pour un lecteur non fragmenté on a une erreur "dépassement de capacité" dans cette portion de code : "Percent of Fragmented files : " & (numFragFiles / numFrag) & vbCrLf &
cause : numFragfiles0 et NumFrag 0 également
Je vais me servir de ton code pour faire un defragmenteur en VB qui sera inclus dans le projet "Acces Direct Disque" si j'y arrive
en tout cas bravo pour ton code : il est très instructif
A+
6 janv. 2007 à 22:03
ShareVB
6 janv. 2007 à 18:04
J'ai un souci avec ton code
Lorsque l'on lance le programme pour la première fois la cartographie de la partition est correcte dans la picturebox avec les zones clusters occupées en bleu et les clusters libres en blanc
Si on change de partition avec le controle Drivelistbox toute la picturebox se remplit en bleu et ne représente plus la cartographie de la partition.
J'ai cherché moi-même en effaçant les tableaux Volvitmap() et temp() avec Erase et les redimensionnant à 0 mais cela ne donne rien
En tout cas très bon programme à part ce petit bug
Merci pour tout
A+
31 déc. 2006 à 15:48
ShareVB
21 déc. 2006 à 21:33
euh, en fait pour la limite des 1024 extents c'était juste une erreur d'offset VCN dans la façon de récupérer les extents...
ShareVB
16 déc. 2006 à 21:32
Au sujet des clusters 0 et 1 pour le système FAT 12,16 ou 32 j'ai des informations plus précises
Le cluster 0 contient le type de media : FF0 ou FFF0 ou FFFFFFF0 pour les disquettes et FF8 ou FFF8 po FFFFFFF8 pour les disques durs suivant le type de FAT
Le cluster 1 contient l'état de la partition : FFF ou FFFF ou FFFFFFFF pour une partition OK et FF7 ou FFF7 ou FFFFFFF7 pour une partition comprenant des erreurs selon le type de FAT
Ces infos sont tirées de Winhex ( logiciel d'édition Héxa-Ascii pour tous types de supports)
14 déc. 2006 à 23:58
Lorsque Windows parle de clusters il parle de VCN "Virtuel Cluster Number" et se référe au premier cluster logique de la FAT
si on prend le VCN n° 0 ce sera le LCN n° 2 (Logical Cluster Number) avec le décalage
On retrouve le même principe dans le Runlist de NTFS
C'est peut-être aussi une convention pour les différences de clusters au niveau FAT
Je mets tout cela au conditionnel car je peux faire erreur
Je vais chercher àen savoir plus car cela me turlupine comme dirait l'autre
A+
14 déc. 2006 à 23:46
A+ et bonne prog
14 déc. 2006 à 22:30
Mais le problème, c'est que si je reformate en FAT16, le bug persiste encore.
Je comprend pas vraiment. Que çà apparaisse en FAT32, ok, mais je ne vois pas pourquoi le bug reste après que je repasse en FAT16.
@+
14 déc. 2006 à 22:21
il semblerait d'après l'article http://www.wd-3.com/archive/luserland.htm, le bug du décalage de 2 dans "get pointers" soit uniquement pour FAT32 (bien que le décalage réel existe aussi sur FAT12 et FAT16)...
ShareVB
14 déc. 2006 à 22:16
-la carte des clusters était bonne avant formatage de ma clé (FAT16)
-la carte est mauvaise (décalage de 2) après le formatage (FAT ou FAT32).
Donc prendre en compte un décalage de 2 clusters pour toutes lse FAT ne marchera pas, puisque la première fois il n'était pas nécessaire.
@+
14 déc. 2006 à 22:00
Je ne peux pas t'en dire plus au niveau du décalage mais c'est confirmé par Winhex ( en FAT les clusters 0 et 1 sont inutilisés). Le premier cluster de la FAT est le cluster n° 2 que ce soit FAT12,FAT 16 ou FAT 32
A+
14 déc. 2006 à 21:03
Mais par contre je dois dire que ma clé, avant formatage, était en FAT16, et il n'y avait pas ce décalage pour autant.
@+
14 déc. 2006 à 21:01
Pour info en FAT 12,16 ou 32 Les clusters 0 et 1 ne sont pas utilisés ( ils avaient été réservés pour le système mais ne furent jamais utilisés à ma connaissance).C'est sûrement pour cette raison que le logiciel de ShareVB renvoie les valeurs 1 et 3680 alors que les clusters réels sont le 3 et 3682
Violent_Ken,tu as écrit : J'ai vérifié, c'est bien 3 et 3683 la "bonne réponse".C'est 3682 normalement vu le décalage de 2
A+
14 déc. 2006 à 15:12
il semblerait que pour FAT32, ce soit une sorte de bug de "retrieval pointers", ce qui n'empêche pas la défragmentation de fonctionner. En fait, le driver ne soustrairait pas les secteurs réservés. On trouve un peu plus sur le sujet à http://www.wd-3.com/archive/luserland.htm...
pour la limite des 1024 extents, effectivement j'ai des fichiers qui ont moins d'extents dans mon logiciel que dans un logiciel professionel...et à peu près à hauteur de 300 en moins...je vais regarder...
ShareVB
14 déc. 2006 à 14:28
Exemple, je colle deux fichiers dans m clé, l'un se place au cluster 3 et l'autre au 3682, ton code me renverra 1 et 3680.
J'ai vérifié, c'est bien 3 et 3683 la "bonne réponse".
Avant formatage, la carte des clusters renvoyées était bonne.
Une idée du problème ?
Merci, @+
10 déc. 2006 à 22:38
Voilà ce que dit Violent_Kken
Sauf que plusieurs fichiers sont considérés comme étant fragmentés en 2 fragments par ton code, mais pas dans les logiciels professionnels.
Pourtant, je confirme que ces fichiers sont bien scindés en 2 (vérifié en regardant le contenu de mon disque dur avec mon éditeur hexa).
Ces fichiers devraient être des fichiers compressés par NTFS qui utilisent des blocs de 16 clusters
Un exemple
LCN 10973 ---> 11 clusters ( clusters physiques) 10973 + 16 = 10989
LCN -1 ---> 5 clusters ( clusters virtuels)
LCN 10989 ---> 3 clusters
LCN -1 ---> 13 clusters
LCN -1 signifie clusters virtuels et dans cet exemple le fichier n'est pas fragmenté pour les logiciels pro mais ils sont bien scindés en 2 pour l'éditeur de disques.
pour ShareVb ton code fonctionne correctement avec les bonnes valeurs au niveau des clusters et j'ai vérifié avec ma source "acces Direct Disque"
par contre, la limite des 1024 extents, je n'ai point testé.
Bravo pour cette source et A+
10 déc. 2006 à 22:14
J'ai un peu modifié le code (changé les 511-2 en 1023-4) et çà passe mieux (j'obtenais bien mes 1383 fragments).
Pour les utilitaires de défragmentation, je trouve les mêmes résultats avec ta source (que j'ai légèrement modifiée pour augmenter la taille à 2047-8) qu'avec eux.
A savoir
-défragmenteur de disque de Windows
-o&o defrag
Sauf que plusieurs fichiers sont considérés comme étant fragmentés en 2 fragments par ton code, mais pas dans les logiciels professionnels.
Pourtant, je confirme que ces fichiers sont bien scindés en 2 (vérifié en regardant le contenu de mon disque dur avec mon éditeur hexa).
@+
10 déc. 2006 à 21:43
le progressbar est corrigé...
par contre, la limite des 1024 extents, je ne vois pas...j'ai des fichiers avec plus de 1300 fragments et ca semble marcher...cependant, je ne sais pas comment les utilitaires de défragmentation comptent, parce que je n'ai pas le même nombre de fragments...
ShareVB
4 déc. 2006 à 23:47
Je vais tester
si Violent_Ken dit "super source" -----> 10/10 d'office
4 déc. 2006 à 19:27
deux petites remarques :
-Progress.Value n'est pas initialisé dans GetVolumeFilesBitmap ==> bug quand on analyse 2 fois de suite (car le .Value est toujours incrémenté après le .Max)
-Il me semble que ExtentCount est limité à 1024 dans ton code ==> bug pour des fichiers avec un nombre de fragment énorme.
Super source, 10/10 ^^
@+