Version imprimable
J'en suis au même point que dans cette discussion et le .bat ne me satisfait pas.
Débuter en Vbs est ardu et toute aide est bienvenue.
Je cherche à m'affranchir du mappage relatif et donc du Net Use, mais aussi des noms longs ingérables en DOS.
Merci d'avance de vos réponses : RTFM : j'ai déja donné :D
Phil
Citation:
Envoyé par Megaxel
Salut,
va voir ici :
http://www.developpez.net/forums/sho...d.php?t=486817
A++
Bon voici le type de compression que tu peux faire avec FSO :
http://activexperts.com/activmonitor...ingFolders.htm
Peut être que cela ne correspond pas à ce que tu veux faire ?
D'ailleurs que veux tu faire ?
Compresser en rar, zip, autre ?
En général pour faire de la compression, on la redévelope sois même, ou on utilise une librairie.
Disons que le script te permettra de faire uniquement ce que sais faire le système d'exploitation.
Windows XP sais compresser et decompresser des Zip en natif, mais pas autre chose.
Peut être alors que certains objets WMI (Windows Management Instrumentation) pourraient le faire, il faudrait chercher.
Mais si tu veux décompresser des .rar par exemples, va falloir trouvé une libririe, ou redev l'algo, par ce que tu ne trouveras rien pour le faire en WSH (Windows Scripting Host), WMI, ou autre ...
Ha ouais, on peut vraiment créer un Zip, et copier dedans un répertoire, comme si le zip n'était qu'un répertoire en fait ?Citation:
Envoyé par RadPAT
Je me demande juste si cela compresse vraiment ou si cela stocke juste dans un zip.
Tu m'as collé une doute sur ce coup là ;)Citation:
Envoyé par ced600
Mais après verification ca compresse effectivement, sur mon poste je passe d'un répertoire de 23MO à un ZIP de 7,7 Mo
A++
Ok pas mal alors ce petit bout de script.
si si, ça compresse bien mais c'est un hack scabreux puisqu'il fonctionne de façon asynchrone d'où la nécessité de prévoir des wscript.sleep au pifomètre :aie:
Hum ... Il doit être possible de faire une fonction qui évite cela :Citation:
Envoyé par omen999
Elle tente le déplacement du fichier en cours de Zip et normalement si le zip n'est pas fini, le script ne devrait pas pouvoir faire le déplacement et recevoir une erreur.
Avec un On Error Resume Next dans la fonction on test l'objet Err, le remet à zéro et renvois true ou false en fonction de l'ancienne valeur.
Ensuite tu fais une autre fonction WaitForZip qui se charge de faire une simple boucle qui appelle la première fonction et tests sa valeur de retour.
Si la copie de fichier se fait quand même alors que le fichier est en cours de zippage, tu fais la même chose que ce que j'ai dit mais en testant l'augmentation de la taille du fichier tous les x temps.
nonCitation:
Hum ... Il doit être possible de faire une fonction qui évite cela :
ça ne change rien puisqu'il faudra bien insérer dans la boucle un sleep sauf à mettre le cpu à 100% :mrgreen:Citation:
Ensuite tu fais une autre fonction WaitForZip qui se charge de faire une simple boucle qui appelle la première fonction et tests sa valeur de retour
mais c'est vrai que ça rendrait l'algo utilisable même sur une machine peu puissante ou déjà soumise à une forte charge
on attend ta contrib vbs... :mouarf:
Merci à vous :
Le problème de ce script est qu'il reste actif après la compression du répertoire.
Je n'ai pas trouvé comment faire pour terminer proprement son exécution.
Une erreur dans le nom d'une variable m'a permis de résoudre mon problème.
Le processus s'arrête correctement maintenant.
Le thread pourrait éventuellement être continué par l'utilisation simple de l'utilitaire de winzip en Vbscript.
Merci encore à tous :)
Oui tu met un sleep mais à 100 millisecondes.Citation:
ça ne change rien puisqu'il faudra bien insérer dans la boucle un sleep sauf à mettre le cpu à 100%
mais c'est vrai que ça rendrait l'algo utilisable même sur une machine peu puissante ou déjà soumise à une forte charge
on attend ta contrib vbs...
Ainsi tu es assez réactif et tu ne prends pas trop de ressources.
C'est bien mieux qu'un sleep de 5 minutes car on ne sait pas combien de temps va prendre la compression ;)