Version imprimable
Bonjour,
Je cherche une solution (portable de préférence) pour récupérer la taille (en octets) d'un cluster de mon disque dur.
J'avais pensé à :
- lire le nombre N1 d'octets libres sur le disque (je ne sais comment faire en portable)
- ensuite créer NF fichiers de 1 octets
- lire le nombre N2 d'octets libres sur le disque
- calculer la taille d'un cluster C = ( N2 - N1 ) / NF
Vous avez déjà écrit une fonction portable de ce style ?
Portable ? non - parce que c'est impossible. La taille du cluster dépends du système de fichier, et le système de fichier dépends en grande partie du système d'exploitation.Citation:
Envoyé par Kaji
Ton algorithme est un exemple frappant : que se passe-t-il si l'os décide de mettre tous les fichiers de 1 octet que tu a créé dans le même cluster ?
Ce qu'il te faut réellement, c'est une fonction bien plus ardue à réaliser : ouvrir le device physique, vérifier le type du système de fichier, et en fonction de la documentation de ce type de FS, trouver la taille d'un cluster. Autrement dit : bon courage :?
Salut,
Cela ne peut normalement pas arriver: un cluster représente une adresse unique, normalement insécable, au même titre que les blocs de 512 octets d'un disque dur.Citation:
Envoyé par Emmanuel Deloget
Tout comme deux fichiers de 1 octets utiliseront en tout au minimum deux blocs de 512 octets, parce qu'il serait impossible de fournir un moyen pour dire que "la première partie du bloc sert pour le fichier 1 et la deuxième pour le fichier 2", un cluster ne peut théoriquement - ou du moins pour ce que j'en sais - ne contenir qu'un seul fichier ;)
En théorie, un cluster est géré par un driver de file system. Si le driver implémente un système de chainage inter-cluster, alors tu peux mettre plusieurs fichiers dans un même cluster. NTFS n'a pas l'aire de le faire, mais je crois me souvenir que cette technique était utilisée sur un OS connu (bien que ma mémoire, défaillante, ne me permette pas de me souvenir lequel).Citation:
Envoyé par koala01
Cependant, un système analogue est supporté sous NTFS, via les flux internes de fichiers (un fichier peut se voir attribuer plusieurs flux). N flux peuvent coexister dans un fichier - ce qui permet d'encoder des méta-données, en plus du système de gestion des méta-données propres à NTFS. Détourner ce système pour créer plusieurs "fichiers" (en fait, plusieurs flux) dans un même cluster est trivial (un nom de fichier avec un flux est noté sous la forme: nonfichier.ext:nomflux). En fait, un driver NTFS ne sait pas lire des fichiers : il ne sait lire que des flux, et les données d'un fichier sont simplement contenue dans un flux non nommé.
Ceci dit, étant donné que je suis dans une phase de recherche, je viens de redécouvrir quelque chose que j'avais oublié : dans certaines conditions (et notamment si le fichier est petit) le fichier et ses données peuvent être stocké directement dans la master file table de la partition NTFS. Dans ce cas, la taille sur disque sera exactement égale à la taille du fichier.
Merci pour ces réponses.
Il me semblait également qu'on ne pouvait écrire qu'un fichier par cluster et que suivant le type de formatage (FAT32 ou NTFS) et la taille du disque, la taille des clusters variait.
Ce qui me manque, pour faire un essai, c'est connaître le nombre d'octets libres sur le disque. Ca existe en C/C++ ?
Je viens de parcourir "Le langage C" / Kernighan, je n'ai pas trouvé.
Il y a peut-être une librairie portable qui donne cette information ?
Ne me dites pas que je vais devoir ajouter un #include<Windows.h> & co ?! :cry: ;)
Ce n'est pas du tout portable mais tu as GetDiskFreeSpace() sous Windows pour connaitre la taille des cluster
http://msdn2.microsoft.com/en-us/lib...35(VS.85).aspx
Effectivement, cette fonction donne :Citation:
Envoyé par ram_0000
- le nombre d'octets par secteur (N1)
- le nombre de secteurs par cluster (N2)
Et donc, la taille d'un cluster c'est N1 x N2.
Ca donne 4096 (4Ko) sur mon disque NTFS.
Merci !