Poids d'un dossier
Bonjour,
je cherche à obtenir la poids d'un dossier.
J'utilise :
Le problème est que j'obtiens tjrs du 324 octets alors que le dossier pèse 226.1Mo
Alors je suppose que le poids du dossier est bien correct... mais il ne compte pas le contenu ?
Alors avez-vous un autre moyen pou récuprer le poids d'un dossier CORRECTEMENT ;D ?
Merci d'avance,
Louka
je cherche à obtenir la poids d'un dossier.
J'utilise :
<br />NSDictionary* _fileAttributes = [_fileManager fileAttributesAtPath:_path traverseLink:NO];<br />long long size = [[_fileAttributes objectForKey:@"NSFileSize"] longLongValue];<br />
Le problème est que j'obtiens tjrs du 324 octets alors que le dossier pèse 226.1Mo
Alors je suppose que le poids du dossier est bien correct... mais il ne compte pas le contenu ?
Alors avez-vous un autre moyen pou récuprer le poids d'un dossier CORRECTEMENT ;D ?
Merci d'avance,
Louka
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
J'ai pas trop regardé le topic qu'a fourni Renaud car je venais de finir de lister le contenu d'un dossier ds un popup en tenant compte des sous-dossiers etc...
Ducoup, récupérer le poids d'un bundle me paraissait bcp plus simple. Alors j'ai fait :
J'obtiens bien le bon poids à quelques Ko près (331ko au lieu de 448Ko par exemple)
En particulier aussi la commande "du" qui donne la place utilisée sur le disque (disk usage) d'un dossier et ce en un temps record... Même si c'est pas tout à fait la taille donnée par le Finder (à qques Ko près, là aussi), pour les raisons expliquées dans ledit post...
Je vous livre directement la méthode que j'utilise:
// calcul de la taille d'un dossier ou d'un "package"
// input: chemin est le "path" du dossier ou du package. ***Not use with Volume***
// return: la taille cherchée.
//
- (unsigned long long)PackSize:(NSString *)chemin :(NSFileManager *)gestion
{
long ret;
FSRef fRef;
NSString *pname, *qname ;
NSDictionary *fattrs ;
FSCatalogInfo catInfo;
unsigned long long P_Size ;
NSString *LaBase = [chemin stringByAppendingString:@/] ; // traitement du chemin
NSDirectoryEnumerator *direnum = [gestion enumeratorAtPath:chemin] ; // prépare l'énumération.
P_Size = 0 ;
while (pname = [direnum nextObject]) { // boucle d'énumération FSSpec
qname = [LaBase stringByAppendingString:pname] ; // nom complet d'un item
ret= FSPathMakeRef((const UInt8 *)[qname UTF8String],&fRef, 0) ; // fait un fRef
fattrs = [gestion fileAttributesAtPath:qname traverseLink:NO]; // prise des attributs
ret=FSGetCatalogInfo(&fRef, KFS_a_moi, &catInfo, NULL, NULL, NULL); // prise des infos.
if ([[fattrs fileType] compare:NSFileTypeSymbolicLink] == NSOrderedSame)
P_Size += [fattrs fileSize] ; // si lien sans partie ressource
else if (!(catInfo.nodeFlags & kFSNodeIsDirectoryMask)) // autre que dossier, package, volume ?
P_Size += catInfo.dataLogicalSize + catInfo.rsrcLogicalSize ;
} ;
return (P_Size);
}
J'espère que vous ne trouverez pas de faille!
A+
joli code. Remplace juste "stringByAppendingString:pname" par "stringByAppendingPathComponent:pname" ainsi que "UTF8String" par "fileSystemRepresentation" et voilà
N'utilise pas utf8string, on sait jamais.
Il se trouve que les noms de fichiers sont stoqués en UTF16 si je ne m'abuse
Et puis même si c'était de l'UTF8 ça te garantirait pas que ça reste comme ça tout le temps)
Il se trouve que l'UTF8 est ainsi fait que, si je ne dis pas de bétise, une chaà®ne avec des caractères standards qui reste dans les codes unicode bas est codée pareil en UTF8 et UTF16.
Mais quand tu pars dans des caractères qui ont des codes Unicode plus grands, le codage sera justement différent en UTF8 et UTF16.
C'est comme l'ISO-Latin-1 qui contient la table ASCII : tant que tu utilises des caractères de la table ASCII (< 128), la table de caractères est la même. Mais au dela les codagse diffèrent.
Bref, pour un système en japonais ou autre langages qui commence à partir dans les aux codes unicodes pour les caractères utilisés, tu risques d'avoir des surprises.