C# - FileCopy - C#/.NET managed - Programmation
Marsh Posté le 24-12-2009 à 12:15:36
ReplyMarsh Posté le 26-12-2009 à 13:10:23
Tamahome a écrit : BackgroundWorker ! |
L'auteur du thread parle d'appli console, le BGWorker est un composant winform il me semble... Et il ne résoud pas le problème.
Si au lieu d'utiliser un simple Copy tu implémentais toi même une écriture tamponnée pas trop bête je pense que tu pourrais très bien gérer la progression de la copie comme tu le souhaites!
Marsh Posté le 26-12-2009 à 22:22:48
Pareil, c'est aussi ce que j'avais compris, mais il a l'air de dire qu'il n'y arrive pas .
Je voulais juste confirmer que j'aurai suivi (à tort ?) la même direction, et que je ne voyais pas la difficulté, il nous faudrait des détails ou du code...
Marsh Posté le 28-12-2009 à 16:37:33
Un truc de ce genre, non ?
Code :
|
Marsh Posté le 28-12-2009 à 17:36:01
Ben je suis au boulot, mais on a un prestataire très frileux qui nous a tout planté notre projet de migration d'ERP, alors voilà quoi, je suis au chômage technique
Marsh Posté le 28-12-2009 à 17:51:13
Seul petit reproche a ton MagicSource, je prefere :
Code :
|
a tes doubles \ mais je suppose que c'est une question de gout
Marsh Posté le 31-12-2009 à 12:07:34
Just for fun, je me suis amusé à rendre le truc multi-threadé avec une jolie GUI et des performances accrues du coup, puisqu'un buffer de 1 Mo permet de pallier aux lenteurs ponctuelles I/O entre les deux threads consommateurs et producteurs.
Program.cs
Code :
|
AdvancedFileManager.cs
Code :
|
Marsh Posté le 31-12-2009 à 14:18:45
En tout cas, à quelques optimisations près, maintenant t'as sous la main un FileCopy asynchrone qui donne des nouvelles en fonction de son avancement à la fois sur le fichier source et le fichier destination
C'est joli, je m'en lasse pas
Marsh Posté le 31-12-2009 à 15:30:23
T'ain je sais pas ce que c'est que la brouette que j'utilise, mais le disque dur est vachement moins rapides que le serveur de fichier... Sur un réseau encombré à 100 Mb, ça fait peur
Marsh Posté le 04-01-2010 à 11:31:38
Ca dépend aussi surtout de l'outil que tu utilises pour effectuer la copie.
En effet, l'Explorateur Windows est une daube infâme en ce qui concerne les performances. Outre la fragmentation (ça, j'y crois pas, car même quand c'est pas fragmenté ça déconne), il passe son temps à accéder à la table d'allocation, et visiblement à y flusher systématiquement toutes les données qu'il écrit dedans. Du coup tout le cache système est inutile. Ensuite, ça semble pas optimisé du tout.
Y'a des tas de logiciels en remplacement de l'explorateur Windows qui sont bien plus rapide pour faire ce genre d'actions. (surtout sous Vista, où c'est vraiment devenu catastrophique)
Marsh Posté le 04-01-2010 à 14:40:50
(faut noter aussi qu'il faut comparer ce qui est comparable)
En effet, je veux pas spécialement me faire l'avocat du diable, mais quand sous Windows Vista tu copies un document, il est réindexé dans la foulé afin que la recherche rapide soit à jour. Eventuellement, le superfetch aussi va se mettre à jour dans la foulée, etc.
Sous Linux, de base, t'as ni superfetch ni indexation qui viennent foutre le bordel et tout ralentir
Marsh Posté le 04-01-2010 à 15:23:29
ReplyMarsh Posté le 04-01-2010 à 15:29:01
Tout comme on peut en mettre une en place sur un serveur Linux
Je dis juste que quand Linux travaille dans le système de fichiers, il fait (en générale) juste ce qu'on lui demande.
Windows, lui, il fait généralement tout un tas de trucs et accessoirement, quand il lui reste du temps, il copie le fichier.
Mais y'a pas moyen d'en tirer des conclusions genre "le système de fichier de windows est moins performant" ou "linux gère mieux la copie des fichiers". C'est juste qu'ils ne font pas la même chose.
Après, je dis pas qui a raison ou non hein C'est débile que copier un répertoire de 1000 fichiers de 1 Ko mette autant de temps que copier 100 Go dans un seul fichier, je suis parfaitement d'accord.
Marsh Posté le 23-12-2009 à 17:20:18
Bonjour,
Je suis débutant en C#; et en train de travailler sur une appli console chargé de copier plusieurs fichiers d'un dossier vers un autre. J'essaye vainement d'afficher un pourcentage ou autre indicateur de la progression de la copy. (FileSystemWatcher, StopWatch). File.copy ne permet que de connaitre la taille avant après mais pas pendant. Je ne souhaite pas utiliser de P/Invoke
Je me suis alors orienté vers la copy via Stream avec une taille de buffer.
J'arrive à copier un fichier vers une destination avec une taille de 1024 par exemple mais je n'arrive pas à trouver un moyen de récuperer la taille de l'OutSream disons par exemple tout les 1/100 de la taille du fichier. Le but serait d'afficher un "=" ou % à chaque fois que la taille de l'Outstream a augmenté d'un bloc de 6MO pour un fichier de 600MO par exemple.
Si quelqu'un peut m'aider ou a déjà eu affaire à cà ?!
Merci