›

Taille des bundles

tabliertablier Membre
17:54 modifié dans API AppKit #1
Comment fait-on pour trouver la taille d'un bundle? C'est a dire la taille indiquée dans la fenêtre d'information du finder.
Merci d'avance.

Réponses

  • Eddy58Eddy58 Membre
    juillet 2005 modifié #2
    Il faut que tu récupères le dictionary retourné par la méthode fileAttributesAtPath:traverseLink: (classe NSFileManager), ensuite tu retrouves la taille avec la clé NSFileSize. (sous forme de NSNumber) :)
  • tabliertablier Membre
    17:54 modifié #3
    Merci pour l'info, je vais re-essayer avec la méthode indiquée.
  • maconnectmaconnect Membre
    17:54 modifié #4
    nop, désolé ça marchera pas.
    Il faut que tu considère ton bundle comme un dossier, que tu parcours l'entier de son contenu et additionnant la taille de chaque élément.
  • amnesicamnesic Membre
    17:54 modifié #5
    dans 1121180187:

    nop, désolé ça marchera pas.
    Il faut que tu considère ton bundle comme un dossier, que tu parcours l'entier de son contenu et additionnant la taille de chaque élément.


    Tu peux aussi utiliser NSTask et faire un :
    du -ks thefullPathOfMyBundle
  • Eddy58Eddy58 Membre
    juillet 2005 modifié #6
    Oui en effet, c'est une chose à  savoir...Voir à  la fin de ce thread sur CocoaDev : http://www.cocoadev.com/index.pl?FileSize
    Il y a un bout de code qui fait le total des différents fichiers, à  tester... :o
  • tabliertablier Membre
    17:54 modifié #7
    Merci à  tous pour vos infos. Je pense que je vais m'en sortir.
    A+
  • tabliertablier Membre
    17:54 modifié #8
    Pour finir sur ce sujet, ma solution (que je trouve un peut alambiquée) est dans le fichier joint. Si vous connaissez plus simple, je suis interéssé.
    Je vous rappel l'objectif: calculer la taille d'un dossier ou d'un paquet avec un résultat identique à  ce qu'indique le finder dans la fenêtre d'info.
    A+

    [Fichier joint supprimé par l'administrateur]
  • amnesicamnesic Membre
    17:54 modifié #9
    dans 1121965053:

    Pour finir sur ce sujet, ma solution (que je trouve un peut alambiquée) est dans le fichier joint. Si vous connaissez plus simple, je suis interéssé.
    Je vous rappel l'objectif: calculer la taille d'un dossier ou d'un paquet avec un résultat identique à  ce qu'indique le finder dans la fenêtre d'info.
    A+




    Effectivement, comme tu me l'as signalé par email, ma solution avec le "du -ks" n'est pas vraiment top. Cela ne donne pas la même valeur que l'info du Finder, car :
    1. c'est une approximation, car "-k" retourne le nombre de blocs de 1Ko octets et pas le nombre octets
    2. mais surtout cela ne tient pas compte de la partie "resource fork" !

    Ta solution fonctionne bien si c'est juste pour un évaluer la taille d'un petit dossier, mais par contre pour évaluer la taille de gros répertoires genre "Applications" par exemple j'ai eu des soucis de swap  (je pense qu'il faudrait faire un pool spécifique pour libérer de temps en temps la mémoire)

    Sinon en repensant à  ton cas, il y a encore un autre moyen que l'on a oublié de lister : C'est la possibilité d'utiliser les AppleScripts.

    Tu peux faire un truc comme ça :


    <br />- (NSNumber *)PackSize2:(NSString *)posixFullPath<br />{<br />    NSString *strSourceAS = [NSString stringWithFormat:@&quot;set fullPathHFS to POSIX file &#092;&quot;%@&#092;&quot; &#092;n tell application &#092;&quot;Finder&#092;&quot; to return size of folder fullPathHFS&quot;,posixFullPath];<br />    <br />    NSAppleScript *asGetSize = [[[NSAppleScript alloc] initWithSource:strSourceAS] autorelease];<br />    <br />    NSString *strResult = [[asGetSize executeAndReturnError:nil] stringValue];<br />    <br />    return [NSNumber numberWithInt:[strResult intValue]];<br />}<br />


    À cette solution je vois comme avantage :
    . Cela peut-être beaucoup plus rapide dans certaine circonstance, car le Finder garde un cache de la taille des dossiers déjà  calculés.
    . Code moins long
    . Tu es sûr d'avoir la même info que le panel du Finder ;-)

    et comme inconvénients :
    . Un peu lent le premier lancement
    . nécessite AppleScript
    . semble bugé de temps en temps (cf. http://forums.macosxhints.com/archive/index.php/t-12088.html)
  • BruBru Membre
    17:54 modifié #10
    dans 1124323592:
    et comme inconvénients :
    . Un peu lent le premier lancement
    . nécessite AppleScript
    . semble bugé de temps en temps (cf. http://forums.macosxhints.com/archive/index.php/t-12088.html)


    Tu peux directement envoyer le bon Apple Event au Finder sans passer par un script pour récupérer cette taille.

    Ainsi, tu gagnes en vitesse (pas de compilation de script), AppleScript n'est pas necessaire. Concernant le bug, je ne sais pas.

    .
  • tabliertablier Membre
    17:54 modifié #11
    pour Amnesic: Je cherchais justement à  me passer des AppleScript, pensant que l'exécution sous Cocoa/Carbon était bien plus rapide!

    Pour Bru: Pour le Bug, je sais: de temps en temps le finder oublie de remettre à  jour les tailles calculées des dossiers.  Pour les Apple events,  je n'ai pas d'idée du tout sur la manière de programmer cela! Un conseil serait le bien venu! (quelles docs? examples?).

    Merci de vos réponses.
  • BruBru Membre
    17:54 modifié #12
    dans 1124354051:
    Pour les Apple events,  je n'ai pas d'idée du tout sur la manière de programmer cela! Un conseil serait le bien venu! (quelles docs? examples?).


    Faut que je retrouve comment on fait (y'a si longtemps). J'utilise les apis Carbon (notamment AESend).

    Le plus dur est de trouver les bons AppleEvent (pour ça, faut se farcir le dictionnaire AppleScript présent dans le Finder).

    Je verrais ça ce soir.

    .
  • SystemSystem
    août 2005 modifié #13
    Tu peux peut être utiliser les "méta données" mais ça limite à  tiger et l'actication de spotlight...
    Pour ça, il te faut créer un MDItem avec MDItemCreate() et obtenir la value (CFNumber) de kMDItemFSSize depuis MDItemCopyAttribute() mais je ne sais pas si ça fonctionne sur les .app (dossiers)...


    Visiblement ça ne marche pas...

    Je n'ai pas lu tous les posts précédents, je poste un bout de code que j'avais fait en espérant ne pas faire doublon, il ne devrait pas être trop lent sur un bundle, s'il peut servir d'exemple.

    - (int)sizeOfFolder:(NSString *)path fman:(NSFileManager*)fman<br />{<br />	NSArray *a=[fman directoryContentsAtPath:path];<br />	if (!a)<br />         return 0;<br /><br />	int k=0;<br />	NSEnumerator *e=[a objectEnumerator];<br />	NSString *item;<br />	while (item=[e nextObject])<br />	{<br />		NSString *s=[path stringByAppendingPathComponent:item];<br />		if ([fman directoryContentsAtPath:s]==nil)<br />		{<br />			NSDictionary *att=[fman fileAttributesAtPath:s traverseLink:NO];<br /><br />			k+=[[att objectForKey:NSFileSize] intValue];<br />		}<br />		else<br />		{<br />			k+=[self sizeOfFolder:s fman:fman];<br />		}<br />	}<br />	return k;<br />}
  • tabliertablier Membre
    17:54 modifié #14
    A Supermic: la documentation précise que "directoryContentsAtPath:" et "objectForKey:NSFileSize" ne tiennent pas compte des ressources!
    Pour mémoire, j'ai une solution qui marche. Voir la pièce jointe du 21 juillet.
    Merci quand même.
Connectez-vous ou Inscrivez-vous pour répondre.