Quelques petites précisions :
Concernant les disques durs, il y a de multiples niveaux de caches. Celui de
Windows en est un. Mais on oublie souvent celui du contrôleur du disque dur
(souvent 2, 4 ou 8 Mo).
Et, quand on parle du cache de windows, il faudrait distinguer : le cache
d'accès aux fichiers, le cache de lancement des programmes (cache externe,
avec prefetch), le cache de DLL (interne, et externe avec DLLcache),
Jouent également : le type de système de fichiers/formatage (NTFS est plus
lent, gestion des derniers accès ou non) ; les antivirus (certains ne
rescanne pas un fichier accédé qq secondes auparavant, d'autres oui) et de
leur configuration ; de certains paramètres de windows (indexation lancée /
pas lancée / désactivée, pour le service et pour le disque).
Il y a encore d'autres éléments.
Il résulte de tout ça que, pour tester la vitesse d'une façon de faire, il
faut faire tourner deux fois, de suite, chaque méthode ; pour diminuer
l'impact des caches. Mais, surtout, IL FAUT ETEINDRE ET REDEMARRER
L'ORDINATEUR ENTRE CHAQUE CHANGEMENT DE METHODE. Un reboot simple ne suffit
pas toujours.
Un autre critère, jouant sur la vitesse, peut être trouvé dans les critères
de sélection des fichiers. Par exemple, si je veux tous les fichiers images
(Jpeg) commençant par ARD, j'utilise : DIR ard*.jpg /S /B alors que les
différents walk nécessitent plus de code, avec un temps d'exécution rallongé
d'autant.
Autre chose : le fait de ne pas obtenir la même chose, entre différentes
méthodes laisse penser à un manque de cohérence, entre les modes de
recherche. En clair, certains paramètres sont mal positionnés. Par exemple,
sur un disque, j'ai plus d'un million de fichiers. Et j'obtiens exactement
la même chose, avec les trois méthodes, sauf si j'examine les répertoires
systèmes, dont le contenu de certains change en continu (surtout à cause des
fichiers temporaires).
Quand aux accents, je suppose qu'il s'agit d'un mauvais choix du code-page
(850 par défaut pour XP), et/ou de police. Car, sur mes configs, non
seulement DIR gère correctement les accents, mais il traite sans problème
des fichiers avec des noms Unicode (plus précisément en cyrillique).
(Éventuellement CMD /U permet de forcer le travail en unicode).
Quelques petites précisions :
Concernant les disques durs, il y a de multiples niveaux de caches. Celui de
Windows en est un. Mais on oublie souvent celui du contrôleur du disque dur
(souvent 2, 4 ou 8 Mo).
Et, quand on parle du cache de windows, il faudrait distinguer : le cache
d'accès aux fichiers, le cache de lancement des programmes (cache externe,
avec prefetch), le cache de DLL (interne, et externe avec DLLcache),
Jouent également : le type de système de fichiers/formatage (NTFS est plus
lent, gestion des derniers accès ou non) ; les antivirus (certains ne
rescanne pas un fichier accédé qq secondes auparavant, d'autres oui) et de
leur configuration ; de certains paramètres de windows (indexation lancée /
pas lancée / désactivée, pour le service et pour le disque).
Il y a encore d'autres éléments.
Il résulte de tout ça que, pour tester la vitesse d'une façon de faire, il
faut faire tourner deux fois, de suite, chaque méthode ; pour diminuer
l'impact des caches. Mais, surtout, IL FAUT ETEINDRE ET REDEMARRER
L'ORDINATEUR ENTRE CHAQUE CHANGEMENT DE METHODE. Un reboot simple ne suffit
pas toujours.
Un autre critère, jouant sur la vitesse, peut être trouvé dans les critères
de sélection des fichiers. Par exemple, si je veux tous les fichiers images
(Jpeg) commençant par ARD, j'utilise : DIR ard*.jpg /S /B alors que les
différents walk nécessitent plus de code, avec un temps d'exécution rallongé
d'autant.
Autre chose : le fait de ne pas obtenir la même chose, entre différentes
méthodes laisse penser à un manque de cohérence, entre les modes de
recherche. En clair, certains paramètres sont mal positionnés. Par exemple,
sur un disque, j'ai plus d'un million de fichiers. Et j'obtiens exactement
la même chose, avec les trois méthodes, sauf si j'examine les répertoires
systèmes, dont le contenu de certains change en continu (surtout à cause des
fichiers temporaires).
Quand aux accents, je suppose qu'il s'agit d'un mauvais choix du code-page
(850 par défaut pour XP), et/ou de police. Car, sur mes configs, non
seulement DIR gère correctement les accents, mais il traite sans problème
des fichiers avec des noms Unicode (plus précisément en cyrillique).
(Éventuellement CMD /U permet de forcer le travail en unicode).
Quelques petites précisions :
Concernant les disques durs, il y a de multiples niveaux de caches. Celui de
Windows en est un. Mais on oublie souvent celui du contrôleur du disque dur
(souvent 2, 4 ou 8 Mo).
Et, quand on parle du cache de windows, il faudrait distinguer : le cache
d'accès aux fichiers, le cache de lancement des programmes (cache externe,
avec prefetch), le cache de DLL (interne, et externe avec DLLcache),
Jouent également : le type de système de fichiers/formatage (NTFS est plus
lent, gestion des derniers accès ou non) ; les antivirus (certains ne
rescanne pas un fichier accédé qq secondes auparavant, d'autres oui) et de
leur configuration ; de certains paramètres de windows (indexation lancée /
pas lancée / désactivée, pour le service et pour le disque).
Il y a encore d'autres éléments.
Il résulte de tout ça que, pour tester la vitesse d'une façon de faire, il
faut faire tourner deux fois, de suite, chaque méthode ; pour diminuer
l'impact des caches. Mais, surtout, IL FAUT ETEINDRE ET REDEMARRER
L'ORDINATEUR ENTRE CHAQUE CHANGEMENT DE METHODE. Un reboot simple ne suffit
pas toujours.
Un autre critère, jouant sur la vitesse, peut être trouvé dans les critères
de sélection des fichiers. Par exemple, si je veux tous les fichiers images
(Jpeg) commençant par ARD, j'utilise : DIR ard*.jpg /S /B alors que les
différents walk nécessitent plus de code, avec un temps d'exécution rallongé
d'autant.
Autre chose : le fait de ne pas obtenir la même chose, entre différentes
méthodes laisse penser à un manque de cohérence, entre les modes de
recherche. En clair, certains paramètres sont mal positionnés. Par exemple,
sur un disque, j'ai plus d'un million de fichiers. Et j'obtiens exactement
la même chose, avec les trois méthodes, sauf si j'examine les répertoires
systèmes, dont le contenu de certains change en continu (surtout à cause des
fichiers temporaires).
Quand aux accents, je suppose qu'il s'agit d'un mauvais choix du code-page
(850 par défaut pour XP), et/ou de police. Car, sur mes configs, non
seulement DIR gère correctement les accents, mais il traite sans problème
des fichiers avec des noms Unicode (plus précisément en cyrillique).
(Éventuellement CMD /U permet de forcer le travail en unicode).
Salut !
Comme par hasard, je tombe, chez un client, sur un problème qui concerne (un
peu) la discussion.
Il s'agit de faire des copies différentielles de certains répertoires, de
plusieurs postes, vers des répertoires réseau. En gros, une vingtaine de
répertoires par postes, pour une trentaine de postes.
Donc, j'ai fait tout ça avec ROBOCOPY (un puissant utilitaire gratuit, de
microsoft, fournit avec les kits de ressources techniques de windows).
En open source, il y a Unison qui est pas mal.
Tant que c'était tout windows, cela a bien fonctionné. Mais, un jour, le
client a acheté un serveur NAS, qui fonctionne avec une sorte de linux
embarqué.
Dès ce moment, toutes les copies sont devenues systématiques, au lieu d'être
différentielles. Résultat : une à deux heures de copie par jour, et par
poste, au lieu de quelques minutes.
Après moult recherches, il s'est avéré que le problème venait de la façon
dont ce linux gère les dates des fichiers. Sous windows (XP, 2000, S2003),
il y a 3 dates : création, dernière modif/écriture, dernier accès. Or, la
version de linux utilisée ne travaille pas de la même façon que windows (par
exemple, la date de création est refaite, au lieu d'être copiée).
Etrange, n'est-ce pas le process client qui décide de la date de
Et, cela n'était pas visible avec un simple DIR. Il fallait utiliser les
commutateurs /TA /TC /TW pour le voir.
Bref, grâce à Python (walk & stat), j'ai réglé le problème.
Comme quoi, aucune solution n'est jamais définitivement valide.
Le pire, c'est que, chez un autre client, qui a aussi un serveur NAS, avec
un linux inconnu, il n'y a pas de problème.
En conclusion, tous les linux ne se comportent pas de la même façon.
Il s'agit probablement plutôt de samba, composant gérant l'émulation de
@-salutations
Michel Claveau
Salut !
Comme par hasard, je tombe, chez un client, sur un problème qui concerne (un
peu) la discussion.
Il s'agit de faire des copies différentielles de certains répertoires, de
plusieurs postes, vers des répertoires réseau. En gros, une vingtaine de
répertoires par postes, pour une trentaine de postes.
Donc, j'ai fait tout ça avec ROBOCOPY (un puissant utilitaire gratuit, de
microsoft, fournit avec les kits de ressources techniques de windows).
En open source, il y a Unison qui est pas mal.
Tant que c'était tout windows, cela a bien fonctionné. Mais, un jour, le
client a acheté un serveur NAS, qui fonctionne avec une sorte de linux
embarqué.
Dès ce moment, toutes les copies sont devenues systématiques, au lieu d'être
différentielles. Résultat : une à deux heures de copie par jour, et par
poste, au lieu de quelques minutes.
Après moult recherches, il s'est avéré que le problème venait de la façon
dont ce linux gère les dates des fichiers. Sous windows (XP, 2000, S2003),
il y a 3 dates : création, dernière modif/écriture, dernier accès. Or, la
version de linux utilisée ne travaille pas de la même façon que windows (par
exemple, la date de création est refaite, au lieu d'être copiée).
Etrange, n'est-ce pas le process client qui décide de la date de
Et, cela n'était pas visible avec un simple DIR. Il fallait utiliser les
commutateurs /TA /TC /TW pour le voir.
Bref, grâce à Python (walk & stat), j'ai réglé le problème.
Comme quoi, aucune solution n'est jamais définitivement valide.
Le pire, c'est que, chez un autre client, qui a aussi un serveur NAS, avec
un linux inconnu, il n'y a pas de problème.
En conclusion, tous les linux ne se comportent pas de la même façon.
Il s'agit probablement plutôt de samba, composant gérant l'émulation de
@-salutations
Michel Claveau
Salut !
Comme par hasard, je tombe, chez un client, sur un problème qui concerne (un
peu) la discussion.
Il s'agit de faire des copies différentielles de certains répertoires, de
plusieurs postes, vers des répertoires réseau. En gros, une vingtaine de
répertoires par postes, pour une trentaine de postes.
Donc, j'ai fait tout ça avec ROBOCOPY (un puissant utilitaire gratuit, de
microsoft, fournit avec les kits de ressources techniques de windows).
En open source, il y a Unison qui est pas mal.
Tant que c'était tout windows, cela a bien fonctionné. Mais, un jour, le
client a acheté un serveur NAS, qui fonctionne avec une sorte de linux
embarqué.
Dès ce moment, toutes les copies sont devenues systématiques, au lieu d'être
différentielles. Résultat : une à deux heures de copie par jour, et par
poste, au lieu de quelques minutes.
Après moult recherches, il s'est avéré que le problème venait de la façon
dont ce linux gère les dates des fichiers. Sous windows (XP, 2000, S2003),
il y a 3 dates : création, dernière modif/écriture, dernier accès. Or, la
version de linux utilisée ne travaille pas de la même façon que windows (par
exemple, la date de création est refaite, au lieu d'être copiée).
Etrange, n'est-ce pas le process client qui décide de la date de
Et, cela n'était pas visible avec un simple DIR. Il fallait utiliser les
commutateurs /TA /TC /TW pour le voir.
Bref, grâce à Python (walk & stat), j'ai réglé le problème.
Comme quoi, aucune solution n'est jamais définitivement valide.
Le pire, c'est que, chez un autre client, qui a aussi un serveur NAS, avec
un linux inconnu, il n'y a pas de problème.
En conclusion, tous les linux ne se comportent pas de la même façon.
Il s'agit probablement plutôt de samba, composant gérant l'émulation de
@-salutations
Michel Claveau
Après moult recherches, il s'est avéré que le problème venait de la façon
dont ce linux gère les dates des fichiers. Sous windows (XP, 2000, S2003),
il y a 3 dates : création, dernière modif/écriture, dernier accès. Or, la
version de linux utilisée ne travaille pas de la même façon que windows (par
exemple, la date de création est refaite, au lieu d'être copiée).
Et, cela n'était pas visible avec un simple DIR. Il fallait utiliser les
commutateurs /TA /TC /TW pour le voir.
Après moult recherches, il s'est avéré que le problème venait de la façon
dont ce linux gère les dates des fichiers. Sous windows (XP, 2000, S2003),
il y a 3 dates : création, dernière modif/écriture, dernier accès. Or, la
version de linux utilisée ne travaille pas de la même façon que windows (par
exemple, la date de création est refaite, au lieu d'être copiée).
Et, cela n'était pas visible avec un simple DIR. Il fallait utiliser les
commutateurs /TA /TC /TW pour le voir.
Après moult recherches, il s'est avéré que le problème venait de la façon
dont ce linux gère les dates des fichiers. Sous windows (XP, 2000, S2003),
il y a 3 dates : création, dernière modif/écriture, dernier accès. Or, la
version de linux utilisée ne travaille pas de la même façon que windows (par
exemple, la date de création est refaite, au lieu d'être copiée).
Et, cela n'était pas visible avec un simple DIR. Il fallait utiliser les
commutateurs /TA /TC /TW pour le voir.
Do Re Mi chel La Si Do wrote:
[zip]Après moult recherches, il s'est avéré que le problème venait de la
façon dont ce linux gère les dates des fichiers. Sous windows (XP,
2000, S2003), il y a 3 dates : création, dernière modif/écriture,
dernier accès. Or, la version de linux utilisée ne travaille pas de
la même façon que windows (par exemple, la date de création est
refaite, au lieu d'être copiée). Et, cela n'était pas visible avec
un simple DIR. Il fallait utiliser les commutateurs /TA /TC /TW pour
le voir.
J'ai déjà vu passer qq chose concernant des problèmes du même genre,
concernant rsync, où la conclusion était qu'il fallait lui donner un
paramètre de fenêtre de temps car la précision utilisée pour dater les
fichiers entre Linux et Windows n'était pas la même.
Do Re Mi chel La Si Do wrote:
[zip]
Après moult recherches, il s'est avéré que le problème venait de la
façon dont ce linux gère les dates des fichiers. Sous windows (XP,
2000, S2003), il y a 3 dates : création, dernière modif/écriture,
dernier accès. Or, la version de linux utilisée ne travaille pas de
la même façon que windows (par exemple, la date de création est
refaite, au lieu d'être copiée). Et, cela n'était pas visible avec
un simple DIR. Il fallait utiliser les commutateurs /TA /TC /TW pour
le voir.
J'ai déjà vu passer qq chose concernant des problèmes du même genre,
concernant rsync, où la conclusion était qu'il fallait lui donner un
paramètre de fenêtre de temps car la précision utilisée pour dater les
fichiers entre Linux et Windows n'était pas la même.
Do Re Mi chel La Si Do wrote:
[zip]Après moult recherches, il s'est avéré que le problème venait de la
façon dont ce linux gère les dates des fichiers. Sous windows (XP,
2000, S2003), il y a 3 dates : création, dernière modif/écriture,
dernier accès. Or, la version de linux utilisée ne travaille pas de
la même façon que windows (par exemple, la date de création est
refaite, au lieu d'être copiée). Et, cela n'était pas visible avec
un simple DIR. Il fallait utiliser les commutateurs /TA /TC /TW pour
le voir.
J'ai déjà vu passer qq chose concernant des problèmes du même genre,
concernant rsync, où la conclusion était qu'il fallait lui donner un
paramètre de fenêtre de temps car la précision utilisée pour dater les
fichiers entre Linux et Windows n'était pas la même.