Un outil Microsoft GRATUIT, fiable et performant pour SAUVEGARDER - SYNCHRONISER : SYNCTOY
30 réponses
webmaster.progitek
Un outil Microsoft GRATUIT, fiable et performant pour SAUVEGARDER -
SYNCHRONISER : SYNCTOY
Nous utilisons Synctoy en v 1.4 depuis plus d'un an tant sous XP que sous
VISTA, et en Réseau !
Depuis 3 mois la version 2.0 en bêta est disponible
Si peu d'utilisateurs connaissent qu'on vous fournit avec plaisir l'adresse
:
-----------------------------------------------------
Windows Vista pour les non-initiés complique le partage des fichiers et des
répertoires.
L'exemple que vous trouverez sur notre site résoud ce problème auquel nous
sommes tous confrontés.
"Pas à Pas ou comment partager totalement et aisément un disque sous Windows
Vista"
Consultable http://www.progitek.com/partage-vista.htm
Editable en PDF en téléchargeant partage-vista.pdf sur www.progitek.com
-----------------------------------------------------
En fait, il y a quand même qq problèmes, de temps à autres. Par exemple, hier, chez un client, source "Windows-2000-serveur", destination un poste d'archivage avec un gros disque.
Message : "Le fichier spécifié n'existe pas".
Ce message apparait 465 fois, sur plus de 18000 fichiers. Robocopy "saute" le fichier, et continue. Mais, si on ne fait pas attention, on ne s'aperçoit pas qu'il manque des fichiers...
Oui, c'est les cas où les fichiers ont été supprimés par quelqu'un pendant l'exécution de Robocopy. On ne peut pas demander à Robocopy de les recréer !.
Alors qu'avec XCopy, j'ai vu de mes yeux des centaines de fichiers existants, non occupés par d'autres applis, et qui n'ont pas été recopiés !
-- Géronte
Bonsoir !
Robocopy est robuste, lui.
En fait, il y a quand même qq problèmes, de temps à autres.
Par exemple, hier, chez un client, source "Windows-2000-serveur",
destination un poste d'archivage avec un gros disque.
Message : "Le fichier spécifié n'existe pas".
Ce message apparait 465 fois, sur plus de 18000 fichiers. Robocopy
"saute" le fichier, et continue. Mais, si on ne fait pas attention, on
ne s'aperçoit pas qu'il manque des fichiers...
Oui, c'est les cas où les fichiers ont été supprimés par quelqu'un
pendant l'exécution de Robocopy. On ne peut pas demander à Robocopy de
les recréer !.
Alors qu'avec XCopy, j'ai vu de mes yeux des centaines de fichiers
existants, non occupés par d'autres applis, et qui n'ont pas été recopiés !
En fait, il y a quand même qq problèmes, de temps à autres. Par exemple, hier, chez un client, source "Windows-2000-serveur", destination un poste d'archivage avec un gros disque.
Message : "Le fichier spécifié n'existe pas".
Ce message apparait 465 fois, sur plus de 18000 fichiers. Robocopy "saute" le fichier, et continue. Mais, si on ne fait pas attention, on ne s'aperçoit pas qu'il manque des fichiers...
Oui, c'est les cas où les fichiers ont été supprimés par quelqu'un pendant l'exécution de Robocopy. On ne peut pas demander à Robocopy de les recréer !.
Alors qu'avec XCopy, j'ai vu de mes yeux des centaines de fichiers existants, non occupés par d'autres applis, et qui n'ont pas été recopiés !
-- Géronte
MCI \(ex do ré Mi chel la si do\) [MVP]
Bonsoir !
Message : "Le fichier spécifié n'existe pas". Oui, c'est le cas où les fichiers ont été supprimés par quelqu'un
pendant l'exécution de Robocopy.
Pas dans ce cas là ! Les archivages se font la nuit, alors que PERSONNE ne travaille (ce sont des fonctionnaires...) De plus, j'arrive à reproduire l'erreur systématiquement, en étant sur le serveur, pour vérifier qu'il n'y a personne de connecté (NET SESSION), et pas de fichiers ouverts ou lockés (NET FILES).
Je me suis fait un jeu d'essai. Mais il est important. Je le reduis petit à petit, lorsque je passe chez le client. Malheureusement, je n'y vais que de temps en temps, et j'ai beaucoup (d'autres) choses à faire. Le diagnostic risque de prendre quelques semaines...
@+ -- Michel Claveau
PS : Robocopy gère bien les fichiers supprimés durant son exécution.
Bonsoir !
Message : "Le fichier spécifié n'existe pas".
Oui, c'est le cas où les fichiers ont été supprimés par quelqu'un
pendant l'exécution de Robocopy.
Pas dans ce cas là !
Les archivages se font la nuit, alors que PERSONNE ne travaille (ce sont
des fonctionnaires...)
De plus, j'arrive à reproduire l'erreur systématiquement, en étant sur
le serveur, pour vérifier qu'il n'y a personne de connecté (NET
SESSION), et pas de fichiers ouverts ou lockés (NET FILES).
Je me suis fait un jeu d'essai. Mais il est important. Je le reduis
petit à petit, lorsque je passe chez le client. Malheureusement, je n'y
vais que de temps en temps, et j'ai beaucoup (d'autres) choses à faire.
Le diagnostic risque de prendre quelques semaines...
@+
--
Michel Claveau
PS : Robocopy gère bien les fichiers supprimés durant son exécution.
Message : "Le fichier spécifié n'existe pas". Oui, c'est le cas où les fichiers ont été supprimés par quelqu'un
pendant l'exécution de Robocopy.
Pas dans ce cas là ! Les archivages se font la nuit, alors que PERSONNE ne travaille (ce sont des fonctionnaires...) De plus, j'arrive à reproduire l'erreur systématiquement, en étant sur le serveur, pour vérifier qu'il n'y a personne de connecté (NET SESSION), et pas de fichiers ouverts ou lockés (NET FILES).
Je me suis fait un jeu d'essai. Mais il est important. Je le reduis petit à petit, lorsque je passe chez le client. Malheureusement, je n'y vais que de temps en temps, et j'ai beaucoup (d'autres) choses à faire. Le diagnostic risque de prendre quelques semaines...
@+ -- Michel Claveau
PS : Robocopy gère bien les fichiers supprimés durant son exécution.
Lognoul, Marc \(Private\)
Bonjour,
net files/net sessions ne rapporteront que les verrous placés via l'accès réseau (CIFS/SMB). Pour trouver l'application qui place un verrou localement, vous pouvez éventuellement utiliser process explorer et sa fonction "find handle", voire utiliser procemon ou filemon. Si le recherche de donne rien et que le fichier est bien verrouillé, c'est le noyau ou un driver (antivirus ou certains systèmes de backup par ex) qui en est la cause (-> redémarrage ou arrêt/désinstallation du driver).
Marc
"MCI (ex do ré Mi chel la si do) [MVP]" wrote in message news:u4#TpU$
Bonsoir !
Message : "Le fichier spécifié n'existe pas". Oui, c'est le cas où les fichiers ont été supprimés par quelqu'un pendant
l'exécution de Robocopy.
Pas dans ce cas là ! Les archivages se font la nuit, alors que PERSONNE ne travaille (ce sont des fonctionnaires...) De plus, j'arrive à reproduire l'erreur systématiquement, en étant sur le serveur, pour vérifier qu'il n'y a personne de connecté (NET SESSION), et pas de fichiers ouverts ou lockés (NET FILES).
Je me suis fait un jeu d'essai. Mais il est important. Je le reduis petit à petit, lorsque je passe chez le client. Malheureusement, je n'y vais que de temps en temps, et j'ai beaucoup (d'autres) choses à faire. Le diagnostic risque de prendre quelques semaines...
@+ -- Michel Claveau
PS : Robocopy gère bien les fichiers supprimés durant son exécution.
Bonjour,
net files/net sessions ne rapporteront que les verrous placés via l'accès
réseau (CIFS/SMB).
Pour trouver l'application qui place un verrou localement, vous pouvez
éventuellement utiliser process explorer et sa fonction "find handle", voire
utiliser procemon ou filemon. Si le recherche de donne rien et que le
fichier est bien verrouillé, c'est le noyau ou un driver (antivirus ou
certains systèmes de backup par ex) qui en est la cause (-> redémarrage ou
arrêt/désinstallation du driver).
Marc
"MCI (ex do ré Mi chel la si do) [MVP]" <enleverlesO.OmcO@OmclaveauO.com>
wrote in message news:u4#TpU$nIHA.4928@TK2MSFTNGP04.phx.gbl...
Bonsoir !
Message : "Le fichier spécifié n'existe pas".
Oui, c'est le cas où les fichiers ont été supprimés par quelqu'un pendant
l'exécution de Robocopy.
Pas dans ce cas là !
Les archivages se font la nuit, alors que PERSONNE ne travaille (ce sont
des fonctionnaires...)
De plus, j'arrive à reproduire l'erreur systématiquement, en étant sur le
serveur, pour vérifier qu'il n'y a personne de connecté (NET SESSION), et
pas de fichiers ouverts ou lockés (NET FILES).
Je me suis fait un jeu d'essai. Mais il est important. Je le reduis petit
à petit, lorsque je passe chez le client. Malheureusement, je n'y vais que
de temps en temps, et j'ai beaucoup (d'autres) choses à faire. Le
diagnostic risque de prendre quelques semaines...
@+
--
Michel Claveau
PS : Robocopy gère bien les fichiers supprimés durant son exécution.
net files/net sessions ne rapporteront que les verrous placés via l'accès réseau (CIFS/SMB). Pour trouver l'application qui place un verrou localement, vous pouvez éventuellement utiliser process explorer et sa fonction "find handle", voire utiliser procemon ou filemon. Si le recherche de donne rien et que le fichier est bien verrouillé, c'est le noyau ou un driver (antivirus ou certains systèmes de backup par ex) qui en est la cause (-> redémarrage ou arrêt/désinstallation du driver).
Marc
"MCI (ex do ré Mi chel la si do) [MVP]" wrote in message news:u4#TpU$
Bonsoir !
Message : "Le fichier spécifié n'existe pas". Oui, c'est le cas où les fichiers ont été supprimés par quelqu'un pendant
l'exécution de Robocopy.
Pas dans ce cas là ! Les archivages se font la nuit, alors que PERSONNE ne travaille (ce sont des fonctionnaires...) De plus, j'arrive à reproduire l'erreur systématiquement, en étant sur le serveur, pour vérifier qu'il n'y a personne de connecté (NET SESSION), et pas de fichiers ouverts ou lockés (NET FILES).
Je me suis fait un jeu d'essai. Mais il est important. Je le reduis petit à petit, lorsque je passe chez le client. Malheureusement, je n'y vais que de temps en temps, et j'ai beaucoup (d'autres) choses à faire. Le diagnostic risque de prendre quelques semaines...
@+ -- Michel Claveau
PS : Robocopy gère bien les fichiers supprimés durant son exécution.
MCI \(ex do ré Mi chel la si do\) [MVP]
Re !
J'insiste : les fichiers ne sont pas verrouillés, ni en cours d'utilisation. J'ai fait un jeu d'essai, avec un répertoire privé, en dehors des espaces partagés. Je peux parfaitement copier les fichiers, avec XCOPY, ou compresser tous les répertoires avec ZipMci. Seul Robocopy accroche.
J'ai cru un moment que c'était lié à des noms de fichiers en Unicode ; mais Robocopy gère bien cela (contrairement à la plupart des utilitaires de backup préconisés par les journaleux...)
Le diagnostioc sera long, car la copie du jeu d'essai prend actuellement 4 h. ; je compte supprimer de nombreux répertoires, jusqu'à isoler le problème. Mais, je ne peux y consacrer qu'un 1/4 h. par semaine...
@+
Michel Claveau
Re !
J'insiste : les fichiers ne sont pas verrouillés, ni en cours
d'utilisation.
J'ai fait un jeu d'essai, avec un répertoire privé, en dehors des
espaces partagés. Je peux parfaitement copier les fichiers, avec XCOPY,
ou compresser tous les répertoires avec ZipMci. Seul Robocopy accroche.
J'ai cru un moment que c'était lié à des noms de fichiers en Unicode ;
mais Robocopy gère bien cela (contrairement à la plupart des utilitaires
de backup préconisés par les journaleux...)
Le diagnostioc sera long, car la copie du jeu d'essai prend actuellement
4 h. ; je compte supprimer de nombreux répertoires, jusqu'à isoler le
problème. Mais, je ne peux y consacrer qu'un 1/4 h. par semaine...
J'insiste : les fichiers ne sont pas verrouillés, ni en cours d'utilisation. J'ai fait un jeu d'essai, avec un répertoire privé, en dehors des espaces partagés. Je peux parfaitement copier les fichiers, avec XCOPY, ou compresser tous les répertoires avec ZipMci. Seul Robocopy accroche.
J'ai cru un moment que c'était lié à des noms de fichiers en Unicode ; mais Robocopy gère bien cela (contrairement à la plupart des utilitaires de backup préconisés par les journaleux...)
Le diagnostioc sera long, car la copie du jeu d'essai prend actuellement 4 h. ; je compte supprimer de nombreux répertoires, jusqu'à isoler le problème. Mais, je ne peux y consacrer qu'un 1/4 h. par semaine...
@+
Michel Claveau
Géronte
Re !
J'insiste : les fichiers ne sont pas verrouillés, ni en cours d'utilisation. J'ai fait un jeu d'essai, avec un répertoire privé, en dehors des espaces partagés. Je peux parfaitement copier les fichiers, avec XCOPY, ou compresser tous les répertoires avec ZipMci. Seul Robocopy accroche.
J'ai cru un moment que c'était lié à des noms de fichiers en Unicode ; mais Robocopy gère bien cela (contrairement à la plupart des utilitaires de backup préconisés par les journaleux...)
Le diagnostioc sera long, car la copie du jeu d'essai prend actuellement 4 h. ; je compte supprimer de nombreux répertoires, jusqu'à isoler le problème. Mais, je ne peux y consacrer qu'un 1/4 h. par semaine...
Alors bon chance pour le diagnostic ! Et bien sûr nous sommes intéressés par le résultat.
-- Géronte
Re !
J'insiste : les fichiers ne sont pas verrouillés, ni en cours
d'utilisation.
J'ai fait un jeu d'essai, avec un répertoire privé, en dehors des
espaces partagés. Je peux parfaitement copier les fichiers, avec XCOPY,
ou compresser tous les répertoires avec ZipMci. Seul Robocopy accroche.
J'ai cru un moment que c'était lié à des noms de fichiers en Unicode ;
mais Robocopy gère bien cela (contrairement à la plupart des utilitaires
de backup préconisés par les journaleux...)
Le diagnostioc sera long, car la copie du jeu d'essai prend actuellement
4 h. ; je compte supprimer de nombreux répertoires, jusqu'à isoler le
problème. Mais, je ne peux y consacrer qu'un 1/4 h. par semaine...
Alors bon chance pour le diagnostic !
Et bien sûr nous sommes intéressés par le résultat.
J'insiste : les fichiers ne sont pas verrouillés, ni en cours d'utilisation. J'ai fait un jeu d'essai, avec un répertoire privé, en dehors des espaces partagés. Je peux parfaitement copier les fichiers, avec XCOPY, ou compresser tous les répertoires avec ZipMci. Seul Robocopy accroche.
J'ai cru un moment que c'était lié à des noms de fichiers en Unicode ; mais Robocopy gère bien cela (contrairement à la plupart des utilitaires de backup préconisés par les journaleux...)
Le diagnostioc sera long, car la copie du jeu d'essai prend actuellement 4 h. ; je compte supprimer de nombreux répertoires, jusqu'à isoler le problème. Mais, je ne peux y consacrer qu'un 1/4 h. par semaine...
Alors bon chance pour le diagnostic ! Et bien sûr nous sommes intéressés par le résultat.
-- Géronte
Géronte
Re !
J'insiste : les fichiers ne sont pas verrouillés, ni en cours d'utilisation. J'ai fait un jeu d'essai, avec un répertoire privé, en dehors des espaces partagés. Je peux parfaitement copier les fichiers, avec XCOPY, ou compresser tous les répertoires avec ZipMci. Seul Robocopy accroche.
J'ai cru un moment que c'était lié à des noms de fichiers en Unicode ; mais Robocopy gère bien cela (contrairement à la plupart des utilitaires de backup préconisés par les journaleux...)
Le diagnostioc sera long, car la copie du jeu d'essai prend actuellement 4 h. ; je compte supprimer de nombreux répertoires, jusqu'à isoler le problème. Mais, je ne peux y consacrer qu'un 1/4 h. par semaine...
Alors bon chance pour le diagnostic ! Et bien sûr nous sommes intéressés par le résultat.
-- Géronte
-- Géronte
Re !
J'insiste : les fichiers ne sont pas verrouillés, ni en cours
d'utilisation.
J'ai fait un jeu d'essai, avec un répertoire privé, en dehors des
espaces partagés. Je peux parfaitement copier les fichiers, avec XCOPY,
ou compresser tous les répertoires avec ZipMci. Seul Robocopy accroche.
J'ai cru un moment que c'était lié à des noms de fichiers en Unicode ;
mais Robocopy gère bien cela (contrairement à la plupart des utilitaires
de backup préconisés par les journaleux...)
Le diagnostioc sera long, car la copie du jeu d'essai prend actuellement
4 h. ; je compte supprimer de nombreux répertoires, jusqu'à isoler le
problème. Mais, je ne peux y consacrer qu'un 1/4 h. par semaine...
Alors bon chance pour le diagnostic !
Et bien sûr nous sommes intéressés par le résultat.
J'insiste : les fichiers ne sont pas verrouillés, ni en cours d'utilisation. J'ai fait un jeu d'essai, avec un répertoire privé, en dehors des espaces partagés. Je peux parfaitement copier les fichiers, avec XCOPY, ou compresser tous les répertoires avec ZipMci. Seul Robocopy accroche.
J'ai cru un moment que c'était lié à des noms de fichiers en Unicode ; mais Robocopy gère bien cela (contrairement à la plupart des utilitaires de backup préconisés par les journaleux...)
Le diagnostioc sera long, car la copie du jeu d'essai prend actuellement 4 h. ; je compte supprimer de nombreux répertoires, jusqu'à isoler le problème. Mais, je ne peux y consacrer qu'un 1/4 h. par semaine...
Alors bon chance pour le diagnostic ! Et bien sûr nous sommes intéressés par le résultat.
-- Géronte
-- Géronte
Azur
Alors bon chance pour le diagnostic ! Et bien sûr nous sommes intéressés par le résultat.
+1
D'autant plus que je rencontre des problème avec Xcopy lors de copie de volume important ( plantage , bouclage, etc...)
avec robocopy pour l'instant pas de problème ....
-azur-
Alors bon chance pour le diagnostic !
Et bien sûr nous sommes intéressés par le résultat.
+1
D'autant plus que je rencontre des problème avec Xcopy lors de copie de
volume
important ( plantage , bouclage, etc...)
Alors bon chance pour le diagnostic ! Et bien sûr nous sommes intéressés par le résultat.
+1
D'autant plus que je rencontre des problème avec Xcopy lors de copie de volume important ( plantage , bouclage, etc...)
avec robocopy pour l'instant pas de problème ....
-azur-
MCI \(ex do ré Mi chel la si do\) [MVP]
Bonjour !
J'ai trouvé !
Le problème vient d'une différence des caractéristiques de formatage. Certains chemins (noms de fichiers/répertoires), en Unicode, dépassent largement les 500 caractères ET contiennent des caractères rejetés.
Je n'ai pas encore pu déterminer quels sont les caractères incriminés, car d'autres noms de fichiers, en grec ou en cyrillique, passent sans problème... Je soupçonne que les parenthèses ( et ) posent problème.
En fait, il n'y a aucun problème, si les disques sources et destination sont tous en NTFS.
Pour mon client, je vais proposer de remplacer son boîtier par du e-SATA (qui est aussi plus rapide).
@-salutations
Michel Claveau
Bonjour !
J'ai trouvé !
Le problème vient d'une différence des caractéristiques de formatage.
Certains chemins (noms de fichiers/répertoires), en Unicode, dépassent
largement les 500 caractères ET contiennent des caractères rejetés.
Je n'ai pas encore pu déterminer quels sont les caractères incriminés,
car d'autres noms de fichiers, en grec ou en cyrillique, passent sans
problème... Je soupçonne que les parenthèses ( et ) posent
problème.
En fait, il n'y a aucun problème, si les disques sources et destination
sont tous en NTFS.
Pour mon client, je vais proposer de remplacer son boîtier par du e-SATA
(qui est aussi plus rapide).
Le problème vient d'une différence des caractéristiques de formatage. Certains chemins (noms de fichiers/répertoires), en Unicode, dépassent largement les 500 caractères ET contiennent des caractères rejetés.
Je n'ai pas encore pu déterminer quels sont les caractères incriminés, car d'autres noms de fichiers, en grec ou en cyrillique, passent sans problème... Je soupçonne que les parenthèses ( et ) posent problème.
En fait, il n'y a aucun problème, si les disques sources et destination sont tous en NTFS.
Pour mon client, je vais proposer de remplacer son boîtier par du e-SATA (qui est aussi plus rapide).
@-salutations
Michel Claveau
Azur
merci du retour.
-azur-
"MCI (ex do ré Mi chel la si do) [MVP]" a écrit dans le message de news:
Bonjour !
J'ai trouvé !
Le problème vient d'une différence des caractéristiques de formatage. Certains chemins (noms de fichiers/répertoires), en Unicode, dépassent largement les 500 caractères ET contiennent des caractères rejetés.
Je n'ai pas encore pu déterminer quels sont les caractères incriminés, car d'autres noms de fichiers, en grec ou en cyrillique, passent sans problème... Je soupçonne que les parenthèses ( et ) posent problème.
En fait, il n'y a aucun problème, si les disques sources et destination sont tous en NTFS.
Pour mon client, je vais proposer de remplacer son boîtier par du e-SATA (qui est aussi plus rapide).
@-salutations
Michel Claveau
merci du retour.
-azur-
"MCI (ex do ré Mi chel la si do) [MVP]" <enleverlesO.OmcO@OmclaveauO.com> a
écrit dans le message de news: O96P3tDpIHA.4672@TK2MSFTNGP05.phx.gbl...
Bonjour !
J'ai trouvé !
Le problème vient d'une différence des caractéristiques de formatage.
Certains chemins (noms de fichiers/répertoires), en Unicode, dépassent
largement les 500 caractères ET contiennent des caractères rejetés.
Je n'ai pas encore pu déterminer quels sont les caractères incriminés, car
d'autres noms de fichiers, en grec ou en cyrillique, passent sans
problème... Je soupçonne que les parenthèses ( et ) posent
problème.
En fait, il n'y a aucun problème, si les disques sources et destination
sont tous en NTFS.
Pour mon client, je vais proposer de remplacer son boîtier par du e-SATA
(qui est aussi plus rapide).
"MCI (ex do ré Mi chel la si do) [MVP]" a écrit dans le message de news:
Bonjour !
J'ai trouvé !
Le problème vient d'une différence des caractéristiques de formatage. Certains chemins (noms de fichiers/répertoires), en Unicode, dépassent largement les 500 caractères ET contiennent des caractères rejetés.
Je n'ai pas encore pu déterminer quels sont les caractères incriminés, car d'autres noms de fichiers, en grec ou en cyrillique, passent sans problème... Je soupçonne que les parenthèses ( et ) posent problème.
En fait, il n'y a aucun problème, si les disques sources et destination sont tous en NTFS.
Pour mon client, je vais proposer de remplacer son boîtier par du e-SATA (qui est aussi plus rapide).
@-salutations
Michel Claveau
Lognoul, Marc \(Private\)
Je ne sais pas si ça intéresse encore qq mais lors d'un test, j'ai reproduit la même erreur dans les conditions suivantes: - file server source rempli de document et de virus - file server destination vide - les deux serveurs fonctionne avec un a-v configuré pour scanner lors des accès. si robocopy copie un fichier infecté, l'a-v tente de l'effacer ou de le mettre en quarantaine, le message d'erreur est affiché si robocopy parvient à copier le fichier, il est scanné sur le serveur de destination, résultat identique copy et xcopy ne donnent pas ces messages d'erreur.
Marc
"MCI (ex do ré Mi chel la si do) [MVP]" wrote in message news:
Re !
J'insiste : les fichiers ne sont pas verrouillés, ni en cours d'utilisation. J'ai fait un jeu d'essai, avec un répertoire privé, en dehors des espaces partagés. Je peux parfaitement copier les fichiers, avec XCOPY, ou compresser tous les répertoires avec ZipMci. Seul Robocopy accroche.
J'ai cru un moment que c'était lié à des noms de fichiers en Unicode ; mais Robocopy gère bien cela (contrairement à la plupart des utilitaires de backup préconisés par les journaleux...)
Le diagnostioc sera long, car la copie du jeu d'essai prend actuellement 4 h. ; je compte supprimer de nombreux répertoires, jusqu'à isoler le problème. Mais, je ne peux y consacrer qu'un 1/4 h. par semaine...
@+
Michel Claveau
Je ne sais pas si ça intéresse encore qq mais lors d'un test, j'ai reproduit
la même erreur dans les conditions suivantes:
- file server source rempli de document et de virus
- file server destination vide
- les deux serveurs fonctionne avec un a-v configuré pour scanner lors des
accès.
si robocopy copie un fichier infecté, l'a-v tente de l'effacer ou de le
mettre en quarantaine, le message d'erreur est affiché
si robocopy parvient à copier le fichier, il est scanné sur le serveur de
destination, résultat identique
copy et xcopy ne donnent pas ces messages d'erreur.
Marc
"MCI (ex do ré Mi chel la si do) [MVP]" <enleverlesO.OmcO@OmclaveauO.com>
wrote in message news:uCUDxTHoIHA.3892@TK2MSFTNGP04.phx.gbl...
Re !
J'insiste : les fichiers ne sont pas verrouillés, ni en cours
d'utilisation.
J'ai fait un jeu d'essai, avec un répertoire privé, en dehors des espaces
partagés. Je peux parfaitement copier les fichiers, avec XCOPY, ou
compresser tous les répertoires avec ZipMci. Seul Robocopy accroche.
J'ai cru un moment que c'était lié à des noms de fichiers en Unicode ;
mais Robocopy gère bien cela (contrairement à la plupart des utilitaires
de backup préconisés par les journaleux...)
Le diagnostioc sera long, car la copie du jeu d'essai prend actuellement 4
h. ; je compte supprimer de nombreux répertoires, jusqu'à isoler le
problème. Mais, je ne peux y consacrer qu'un 1/4 h. par semaine...
Je ne sais pas si ça intéresse encore qq mais lors d'un test, j'ai reproduit la même erreur dans les conditions suivantes: - file server source rempli de document et de virus - file server destination vide - les deux serveurs fonctionne avec un a-v configuré pour scanner lors des accès. si robocopy copie un fichier infecté, l'a-v tente de l'effacer ou de le mettre en quarantaine, le message d'erreur est affiché si robocopy parvient à copier le fichier, il est scanné sur le serveur de destination, résultat identique copy et xcopy ne donnent pas ces messages d'erreur.
Marc
"MCI (ex do ré Mi chel la si do) [MVP]" wrote in message news:
Re !
J'insiste : les fichiers ne sont pas verrouillés, ni en cours d'utilisation. J'ai fait un jeu d'essai, avec un répertoire privé, en dehors des espaces partagés. Je peux parfaitement copier les fichiers, avec XCOPY, ou compresser tous les répertoires avec ZipMci. Seul Robocopy accroche.
J'ai cru un moment que c'était lié à des noms de fichiers en Unicode ; mais Robocopy gère bien cela (contrairement à la plupart des utilitaires de backup préconisés par les journaleux...)
Le diagnostioc sera long, car la copie du jeu d'essai prend actuellement 4 h. ; je compte supprimer de nombreux répertoires, jusqu'à isoler le problème. Mais, je ne peux y consacrer qu'un 1/4 h. par semaine...
