J'écris une application multiplate-forme et j'ai besoin de l'espace disque disponible total disponible. Pour les systèmes POSIX (Linux et MacOS), j'utilise STTVFS. J'ai créé cette méthode C ++: Malheureusement, je reçois des valeurs assez étranges que je ne peux pas comprendre. Par exemple:
f_blocks = 73242188
f_bsize = 1048576
f_bfree = 50393643
... sont ces valeurs dans les bits, octets ou autre chose? J'ai lu ici sur Stackoverflow ceux qui devraient être des octets, mais j'aurais alors le nombre total d'octets libres est:
f_bsize * f_bfree = 1048576 * 50393643
Mais cela signifie 49212.542 Go ... Trop de ... Est-ce que je fais quelque chose de mal avec le code ou quoi que ce soit d'autre?
Merci!
4 Réponses :
Je ne connais pas assez bien OSX pour prédire que cela est définitivement la réponse, mais http://www.opengroup.org/onlinePubs/ 009695399 / BEAYEFS / SYS / STATVFS.H.HTML
f_blocks et f_bfree se réfère réellement à "Blocs fondamentaux" ou "Fragments" ( qui sont de taille buf.f_frsize octets), pas la "taille du bloc de système de fichiers" (qui est buf.f_bsize octets):
f_bsize est juste un indice quelle est la taille préférée des opérations d'E / S, ce n'est pas nécessairement rien à voir avec la manière dont le système de fichiers est divisé.
Je suppose que les deux dernières réponses sont correctes et utiles. Cependant, je suis résolu en remplaçant simplement la fonction statvfs avec la fonction STATFS . La taille du bloc est alors 4096 comme prévu et tout semble être correct. Merci!
Je ne peux pas voir où STATFS est obsolète sur OS X. Aussi STATFS produit les valeurs correctes.
Je ne peux pas non plus voir que: développeur.apple.com/library/mac/#documentation/darwin/refere nce / ... .
Documentation Apple dit ceci à la fin de STATTVFS Doc: les fonctions STTVFS () et FSTATVFS () sont conformes à l'IEEE STD 1003.1-2001 (`` POSIX.1 ''). À mesure que les applications portatives standardisées ne peuvent pas dépendre de ces fonctions renvoyant des informations valides du tout. Cette mise en œuvre tente de fournir autant d'informations utiles que prévu par le système de fichiers sous-jacent, sous réserve des limitations des types de données spécifiés.
Les lignes suivantes:
unsigned long long disk_size = (unsigned long long) (blocks) * (unsigned long long) (blksize)
Bonne prise! J'ai aussi vu les chiffres étranges étant (non signé longtemps)
uint64_t userAvailableFreeSpace()
{
struct statvfs stat;
struct passwd *pw = getpwuid(getuid());
if ( NULL != pw && 0 == statvfs(pw->pw_dir, &stat) )
{
uint64_t freeBytes = (uint64_t)stat.f_bavail * stat.f_frsize;
return freeBytes;
}
return 0ULL;
}
Quel système de fichiers utilisez-vous qui a une taille de bloc de 1048576?
Ceci est un système d'exploitation Mac étendu (sensible à la casse, journalisée). En ce moment, je travaille sur Mac, mais aussi loin que je peux comprendre, cela est censé travailler.
En plus de l'étrangeté avec votre taille de bloc et votre allégation de disque de 70 To - méfiez-vous qu'un
long sur 32 bits osx est de seulement 32 bits. Même une fois que vous avez les bons chiffres, c'est probablement assez gros pour votre nombre de blocks , mais pas assez grand pour votre nombre de octets . Les entraînements aussi grands que 4 Go sont facilement disponibles auprès de fournisseurs spécialisés ;-)Outre l'erreur sur le type retourné, aucune raison pour que je reçois des valeurs étranges dans la structure? Toute autre façon d'obtenir ces valeurs? Merci!
Ah, maintenant que je prends de plus près, vérifiez si
f_bsize etf_frsize est égal. Je parie qu'ils ne sont pas. Le nombre de blocs et de blocs libres se référer àf_frsize , pasf_bsize .