Aujourd'hui je ne "fais" pas vraiment "dans" l'innovation, puisque je me
suis retrouvé face à des programmes de sauvegarde qui manquaient de
mémoire tantôt l'un, tantôt l'autre, sans que personne ne réussisse à
trouver une explication.
J'ai donc écrit mon propre joujou.
J'avais d'abord pensé parcourir un répertoire par Dir(), mais Dir a du
mal à être récursif : quand on liste un sous-répertoire, une fois qu'on
revient au répertoire ascendant, Dir retourne une erreur.
Il aurait donc fallu créer un tableau de chaînes pour chaque répertoire,
parcourir le répertoire trois fois, une fois pour dimensionner le
tableau, une fois pour le renseigner, et une fois pour traiter les
sous-répertoires. En ne sachant pas dans l'absolu combien on aura de
répertoires à traiter. Ou alors utiliser des tableaux dynamiques, ça
marche bien, ça, dans ce cas ?
Finalement je me suis simplifié l'existence, j'ai utilisé
FileSystemObject. ça fait l'objet de critiques, fso utilise beaucoup de
ressources, mais question récursivité, aucun souci il me semble.
Et justement, mon développement sur le traitement le plus basique et
universel qui soit, était motivé par le fait que les commandes standard
(XCOPY, Robocopy) ... manquaient de ressources. Pour XCOPY : traitement
interrompu, mémoire insuffisante. Pour Robocopy : même pas besoin d'en
dire autant. On copie normalement pendant cinq secondes, poussivement
pendant les cinq secondes suivantes, et ensuite il ne se passe plus
rien, les témoins des disques sont éteints, on attend que l'utilisateur
interrompe le traitement par le gestionnaire des tâches. Et fso s'en est
très bien sorti de ce point de vue.
J'ai donc quelque chose du style
Public Sub GereRepertoire(ByVal Rep As Folder)
Set objSousReps = Rep.SubFolders
For Each Fic in Rep.Files
GereFichier Fic
Next
For Each SR in objSousReps
GereRepertoire fso.GetFolder(SR.path)
Next
End Sub
ça fait peut-être un peu lourd fso.GetFolder(SR.path) pour retourner SR,
je ne me rappelle plus trop mais je pense que si j'ai fait comme ça
c'est que je devais avoir un message d'erreur autrement.
Quelque chose que j'apprécie bien c'est que ça va jusqu'au bout sans se
planter, ni me dire qu'on manque de mémoire.
Mais là, me voilà pris d'un doute : j'ai cherché un fichier, et j'ai dû
aller le prendre sur la source, il n'avait pas été copié.
Je me suis dit qu'il avait dû y avoir une erreur que j'avais oubliée,
ben non, le fichier n'est pas inscrit dans le compte-rendu de sauvegarde.
Quelque chose me dit quand même que si mon algorithme était complètement
délirant il en manquerait plus que ça.
La vérification désoriente un peu d'ailleurs, car l'explorateur trie
obligatoirement les fichiers, alors que For Each file in, les retourne
apparemment dans l'ordre de la création. Enfin ça c'est anecdotique.
Il y aura une recherche d'un outil de vérification, pour comparer la
source et la cible, mais la question qui relève de ce newsgroup serait
surtout la suivante : y a-t-il une grossière erreur dans ma démarche ?
Avec la procédure que j'ai indiquée ci-dessus, peut-on s'attendre à ce
que GereFichier ne soit pas appelé pour tous les fichiers ?
For Each SR in objSousReps GereRepertoire fso.GetFolder(SR.path)
et GereRepertoire SR ?
Mais là, me voilà pris d'un doute : j'ai cherché un fichier, et j'ai dû aller le prendre sur la source, il n'avait pas été copié.
Tu ne donnes pas le code de GèreFichier. L'erreur est peut-être dedans ? Un fichier verrouillé au moment de l'appel peut-être ?
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
Clive Lumb
Gloops wrote:
Bonjour tout le monde,
Aujourd'hui je ne "fais" pas vraiment "dans" l'innovation, puisque je me suis retrouvé face à des programmes de sauvegarde qui manquaient de mémoire tantôt l'un, tantôt l'autre, sans que personne ne réussisse à trouver une explication.
J'ai donc écrit mon propre joujou.
J'avais d'abord pensé parcourir un répertoire par Dir(), mais Dir a du mal à être récursif : quand on liste un sous-répertoire, une fois qu'on revient au répertoire ascendant, Dir retourne une erreur.
Il aurait donc fallu créer un tableau de chaînes pour chaque répertoire, parcourir le répertoire trois fois, une fois pour dimensionner le tableau, une fois pour le renseigner, et une fois pour traiter les sous-répertoires. En ne sachant pas dans l'absolu combien on aura de répertoires à traiter. Ou alors utiliser des tableaux dynamiques, ça marche bien, ça, dans ce cas ?
Finalement je me suis simplifié l'existence, j'ai utilisé FileSystemObject. ça fait l'objet de critiques, fso utilise beaucoup de ressources, mais question récursivité, aucun souci il me semble.
Et justement, mon développement sur le traitement le plus basique et universel qui soit, était motivé par le fait que les commandes standard (XCOPY, Robocopy) ... manquaient de ressources. Pour XCOPY : traitement interrompu, mémoire insuffisante. Pour Robocopy : même pas besoin d'en dire autant. On copie normalement pendant cinq secondes, poussivement pendant les cinq secondes suivantes, et ensuite il ne se passe plus rien, les témoins des disques sont éteints, on attend que l'utilisateur interrompe le traitement par le gestionnaire des tâches. Et fso s'en est très bien sorti de ce point de vue.
<SNIP>
[un peu HS]
Que Robocopy ne marche pas m'étonne énormement. Je l'utilise (en version 2003) pour diverses applications, entre serveurs, sur des disques durs usb etc., jamais des problèmes de manque de ressources, jamais de traitement interrompu. Je serais tenté de soupçonner un problème ailleurs: de disque, driver ide, carte réseau etc.
Clive
Gloops wrote:
Bonjour tout le monde,
Aujourd'hui je ne "fais" pas vraiment "dans" l'innovation, puisque je
me suis retrouvé face à des programmes de sauvegarde qui manquaient de
mémoire tantôt l'un, tantôt l'autre, sans que personne ne réussisse à
trouver une explication.
J'ai donc écrit mon propre joujou.
J'avais d'abord pensé parcourir un répertoire par Dir(), mais Dir a du
mal à être récursif : quand on liste un sous-répertoire, une fois
qu'on revient au répertoire ascendant, Dir retourne une erreur.
Il aurait donc fallu créer un tableau de chaînes pour chaque
répertoire, parcourir le répertoire trois fois, une fois pour
dimensionner le tableau, une fois pour le renseigner, et une fois
pour traiter les sous-répertoires. En ne sachant pas dans l'absolu
combien on aura de répertoires à traiter. Ou alors utiliser des
tableaux dynamiques, ça marche bien, ça, dans ce cas ?
Finalement je me suis simplifié l'existence, j'ai utilisé
FileSystemObject. ça fait l'objet de critiques, fso utilise beaucoup
de ressources, mais question récursivité, aucun souci il me semble.
Et justement, mon développement sur le traitement le plus basique et
universel qui soit, était motivé par le fait que les commandes
standard (XCOPY, Robocopy) ... manquaient de ressources. Pour XCOPY :
traitement interrompu, mémoire insuffisante. Pour Robocopy : même pas
besoin d'en dire autant. On copie normalement pendant cinq secondes,
poussivement pendant les cinq secondes suivantes, et ensuite il ne se
passe plus rien, les témoins des disques sont éteints, on attend que
l'utilisateur interrompe le traitement par le gestionnaire des
tâches. Et fso s'en est très bien sorti de ce point de vue.
<SNIP>
[un peu HS]
Que Robocopy ne marche pas m'étonne énormement.
Je l'utilise (en version 2003) pour diverses applications, entre serveurs,
sur des disques durs usb etc., jamais des problèmes de manque de ressources,
jamais de traitement interrompu.
Je serais tenté de soupçonner un problème ailleurs: de disque, driver ide,
carte réseau etc.
Aujourd'hui je ne "fais" pas vraiment "dans" l'innovation, puisque je me suis retrouvé face à des programmes de sauvegarde qui manquaient de mémoire tantôt l'un, tantôt l'autre, sans que personne ne réussisse à trouver une explication.
J'ai donc écrit mon propre joujou.
J'avais d'abord pensé parcourir un répertoire par Dir(), mais Dir a du mal à être récursif : quand on liste un sous-répertoire, une fois qu'on revient au répertoire ascendant, Dir retourne une erreur.
Il aurait donc fallu créer un tableau de chaînes pour chaque répertoire, parcourir le répertoire trois fois, une fois pour dimensionner le tableau, une fois pour le renseigner, et une fois pour traiter les sous-répertoires. En ne sachant pas dans l'absolu combien on aura de répertoires à traiter. Ou alors utiliser des tableaux dynamiques, ça marche bien, ça, dans ce cas ?
Finalement je me suis simplifié l'existence, j'ai utilisé FileSystemObject. ça fait l'objet de critiques, fso utilise beaucoup de ressources, mais question récursivité, aucun souci il me semble.
Et justement, mon développement sur le traitement le plus basique et universel qui soit, était motivé par le fait que les commandes standard (XCOPY, Robocopy) ... manquaient de ressources. Pour XCOPY : traitement interrompu, mémoire insuffisante. Pour Robocopy : même pas besoin d'en dire autant. On copie normalement pendant cinq secondes, poussivement pendant les cinq secondes suivantes, et ensuite il ne se passe plus rien, les témoins des disques sont éteints, on attend que l'utilisateur interrompe le traitement par le gestionnaire des tâches. Et fso s'en est très bien sorti de ce point de vue.
<SNIP>
[un peu HS]
Que Robocopy ne marche pas m'étonne énormement. Je l'utilise (en version 2003) pour diverses applications, entre serveurs, sur des disques durs usb etc., jamais des problèmes de manque de ressources, jamais de traitement interrompu. Je serais tenté de soupçonner un problème ailleurs: de disque, driver ide, carte réseau etc.
Clive
bayosky
Dans le message , Gloops a écrit :
Bonjour tout le monde,
Salut,
il faudrait voir sur le groupe scripting mais , justement j'ai fait un script récement qui balaye un répertoire de profondeur inconnu pour y rechercher et certains fichiers et je n'ai aucun pb ...
cela ressemble beaucoup à ce que tu proposes.. je ne vois pas trop l'avantage de objsousreps et le coup de getfolder(sr.path ) me semble bizarre L'avantage de la collection Subfolders est justement que l'on balaye les sous répertoires sans se préoccuper des chemins...
Ton Pb vient peut-être de l'objet Folder lui même :
Celui de VB : dans ta procédure : (ByVal Rep As Folder) et celui du FSO est-ce sans incidence ????? C'estsans doute pour cela que tu as besoin du sSR.path
SR est un objet "VB" ta manip le transforme en objet "du FSO"
le pb est que tu le transmet ainsi comme variable VB as folder ( VB)
Ce serait plus clair si tu le laissait en variant pour qu'il ne change pas de nature en cachette En ce qui concerne mon script, il est sans mystère : Je viens de tester son adaptation en VB6 ..;
pas de pb
je déclare les variables sans type ...
CDepart est le chemin de départ ' ************************* Dim FSO, FDepart, CDepart
Sub Vazi Set FSO = CreateObject("Scripting.FileSystemObject") Set FDepart = FSO.GetFolder(CDepart) Call traite(FDepart) End Sub ' ***************************
etc ...
' **************************************** Sub traite(ByVal fd)
For Each sf in fd.Files ' test et traitement du "fichier" sf ' Attention c'est un objet hérité du FSO ' les propriétés et méthodes à utiliser en découlent... ' Sinon en passant par le Path on peut faire un objet "natif" VB... Next For Each sfg in fd.SubFolders Call traite(sfg) Next
End Sub
Dans le message uhVfJXTSGHA.424@TK2MSFTNGP12.phx.gbl,
Gloops <gloops@niark.invalid> a écrit :
Bonjour tout le monde,
Salut,
il faudrait voir sur le groupe scripting mais , justement j'ai fait un
script récement qui balaye un répertoire de profondeur inconnu pour y
rechercher et certains fichiers et je n'ai aucun pb ...
cela ressemble beaucoup à ce que tu proposes..
je ne vois pas trop l'avantage de objsousreps et
le coup de getfolder(sr.path ) me semble bizarre
L'avantage de la collection Subfolders est justement que l'on balaye
les sous répertoires sans se préoccuper des chemins...
Ton Pb vient peut-être de l'objet Folder lui même :
Celui de VB : dans ta procédure : (ByVal Rep As Folder)
et celui du FSO
est-ce sans incidence ?????
C'estsans doute pour cela que tu as besoin du sSR.path
SR est un objet "VB"
ta manip le transforme en objet "du FSO"
le pb est que tu le transmet ainsi comme variable VB as folder ( VB)
Ce serait plus clair si tu le laissait en variant pour qu'il ne change
pas de nature en cachette
En ce qui concerne mon script, il est sans mystère :
Je viens de tester son adaptation en VB6 ..;
pas de pb
je déclare les variables sans type ...
CDepart est le chemin de départ
' *************************
Dim FSO, FDepart, CDepart
Sub Vazi
Set FSO = CreateObject("Scripting.FileSystemObject")
Set FDepart = FSO.GetFolder(CDepart)
Call traite(FDepart)
End Sub
' ***************************
etc ...
' ****************************************
Sub traite(ByVal fd)
For Each sf in fd.Files
' test et traitement du "fichier" sf
' Attention c'est un objet hérité du FSO
' les propriétés et méthodes à utiliser en découlent...
' Sinon en passant par le Path on peut faire un objet
"natif" VB...
Next
For Each sfg in fd.SubFolders
Call traite(sfg)
Next
il faudrait voir sur le groupe scripting mais , justement j'ai fait un script récement qui balaye un répertoire de profondeur inconnu pour y rechercher et certains fichiers et je n'ai aucun pb ...
cela ressemble beaucoup à ce que tu proposes.. je ne vois pas trop l'avantage de objsousreps et le coup de getfolder(sr.path ) me semble bizarre L'avantage de la collection Subfolders est justement que l'on balaye les sous répertoires sans se préoccuper des chemins...
Ton Pb vient peut-être de l'objet Folder lui même :
Celui de VB : dans ta procédure : (ByVal Rep As Folder) et celui du FSO est-ce sans incidence ????? C'estsans doute pour cela que tu as besoin du sSR.path
SR est un objet "VB" ta manip le transforme en objet "du FSO"
le pb est que tu le transmet ainsi comme variable VB as folder ( VB)
Ce serait plus clair si tu le laissait en variant pour qu'il ne change pas de nature en cachette En ce qui concerne mon script, il est sans mystère : Je viens de tester son adaptation en VB6 ..;
pas de pb
je déclare les variables sans type ...
CDepart est le chemin de départ ' ************************* Dim FSO, FDepart, CDepart
Sub Vazi Set FSO = CreateObject("Scripting.FileSystemObject") Set FDepart = FSO.GetFolder(CDepart) Call traite(FDepart) End Sub ' ***************************
etc ...
' **************************************** Sub traite(ByVal fd)
For Each sf in fd.Files ' test et traitement du "fichier" sf ' Attention c'est un objet hérité du FSO ' les propriétés et méthodes à utiliser en découlent... ' Sinon en passant par le Path on peut faire un objet "natif" VB... Next For Each sfg in fd.SubFolders Call traite(sfg) Next
End Sub
Clive Lumb
Gloops wrote:
Bonjour tout le monde,
Aujourd'hui je ne "fais" pas vraiment "dans" l'innovation, puisque je me suis retrouvé face à des programmes de sauvegarde qui manquaient de mémoire tantôt l'un, tantôt l'autre, sans que personne ne réussisse à trouver une explication.
J'ai donc écrit mon propre joujou.
J'avais d'abord pensé parcourir un répertoire par Dir(), mais Dir a du mal à être récursif : quand on liste un sous-répertoire, une fois qu'on revient au répertoire ascendant, Dir retourne une erreur.
Il aurait donc fallu créer un tableau de chaînes pour chaque répertoire, parcourir le répertoire trois fois, une fois pour dimensionner le tableau, une fois pour le renseigner, et une fois pour traiter les sous-répertoires. En ne sachant pas dans l'absolu combien on aura de répertoires à traiter. Ou alors utiliser des tableaux dynamiques, ça marche bien, ça, dans ce cas ?
Il y a un très bon exemple dans l'API Guide sous "GetFileAttributes" dont tu pourrais t'inspirer. Cela utilise la recursivité à fond. C'est assez rapide aussi.
Clive
Gloops wrote:
Bonjour tout le monde,
Aujourd'hui je ne "fais" pas vraiment "dans" l'innovation, puisque je
me suis retrouvé face à des programmes de sauvegarde qui manquaient de
mémoire tantôt l'un, tantôt l'autre, sans que personne ne réussisse à
trouver une explication.
J'ai donc écrit mon propre joujou.
J'avais d'abord pensé parcourir un répertoire par Dir(), mais Dir a du
mal à être récursif : quand on liste un sous-répertoire, une fois
qu'on revient au répertoire ascendant, Dir retourne une erreur.
Il aurait donc fallu créer un tableau de chaînes pour chaque
répertoire, parcourir le répertoire trois fois, une fois pour
dimensionner le tableau, une fois pour le renseigner, et une fois
pour traiter les sous-répertoires. En ne sachant pas dans l'absolu
combien on aura de répertoires à traiter. Ou alors utiliser des
tableaux dynamiques, ça marche bien, ça, dans ce cas ?
Il y a un très bon exemple dans l'API Guide sous "GetFileAttributes" dont tu
pourrais t'inspirer. Cela utilise la recursivité à fond.
C'est assez rapide aussi.
Aujourd'hui je ne "fais" pas vraiment "dans" l'innovation, puisque je me suis retrouvé face à des programmes de sauvegarde qui manquaient de mémoire tantôt l'un, tantôt l'autre, sans que personne ne réussisse à trouver une explication.
J'ai donc écrit mon propre joujou.
J'avais d'abord pensé parcourir un répertoire par Dir(), mais Dir a du mal à être récursif : quand on liste un sous-répertoire, une fois qu'on revient au répertoire ascendant, Dir retourne une erreur.
Il aurait donc fallu créer un tableau de chaînes pour chaque répertoire, parcourir le répertoire trois fois, une fois pour dimensionner le tableau, une fois pour le renseigner, et une fois pour traiter les sous-répertoires. En ne sachant pas dans l'absolu combien on aura de répertoires à traiter. Ou alors utiliser des tableaux dynamiques, ça marche bien, ça, dans ce cas ?
Il y a un très bon exemple dans l'API Guide sous "GetFileAttributes" dont tu pourrais t'inspirer. Cela utilise la recursivité à fond. C'est assez rapide aussi.
Clive
Gloops
Euh, si tu pouvais me le refaire au ralenti, ça serait sympa :) _________________ bayosky a écrit :
Dans le message , Gloops a écrit :
Bonjour tout le monde,
Salut,
il faudrait voir sur le groupe scripting mais , justement j'ai fait un script récement qui balaye un répertoire de profondeur inconnu pour y rechercher et certains fichiers et je n'ai aucun pb ...
cela ressemble beaucoup à ce que tu proposes.. je ne vois pas trop l'avantage de objsousreps et le coup de getfolder(sr.path ) me semble bizarre L'avantage de la collection Subfolders est justement que l'on balaye les sous répertoires sans se préoccuper des chemins...
Ton Pb vient peut-être de l'objet Folder lui même :
Celui de VB : dans ta procédure : (ByVal Rep As Folder) et celui du FSO est-ce sans incidence ????? C'estsans doute pour cela que tu as besoin du sSR.path
SR est un objet "VB" ta manip le transforme en objet "du FSO"
le pb est que tu le transmet ainsi comme variable VB as folder ( VB)
Ce serait plus clair si tu le laissait en variant pour qu'il ne change pas de nature en cachette En ce qui concerne mon script, il est sans mystère : Je viens de tester son adaptation en VB6 ..;
pas de pb
je déclare les variables sans type ...
CDepart est le chemin de départ ' ************************* Dim FSO, FDepart, CDepart
Sub Vazi Set FSO = CreateObject("Scripting.FileSystemObject") Set FDepart = FSO.GetFolder(CDepart) Call traite(FDepart) End Sub ' ***************************
etc ...
' **************************************** Sub traite(ByVal fd)
For Each sf in fd.Files ' test et traitement du "fichier" sf ' Attention c'est un objet hérité du FSO ' les propriétés et méthodes à utiliser en découlent... ' Sinon en passant par le Path on peut faire un objet "natif" VB... Next For Each sfg in fd.SubFolders Call traite(sfg) Next
End Sub
Euh, si tu pouvais me le refaire au ralenti, ça serait sympa :)
_________________
bayosky a écrit :
Dans le message uhVfJXTSGHA.424@TK2MSFTNGP12.phx.gbl,
Gloops <gloops@niark.invalid> a écrit :
Bonjour tout le monde,
Salut,
il faudrait voir sur le groupe scripting mais , justement j'ai fait un
script récement qui balaye un répertoire de profondeur inconnu pour y
rechercher et certains fichiers et je n'ai aucun pb ...
cela ressemble beaucoup à ce que tu proposes..
je ne vois pas trop l'avantage de objsousreps et
le coup de getfolder(sr.path ) me semble bizarre
L'avantage de la collection Subfolders est justement que l'on balaye les
sous répertoires sans se préoccuper des chemins...
Ton Pb vient peut-être de l'objet Folder lui même :
Celui de VB : dans ta procédure : (ByVal Rep As Folder)
et celui du FSO
est-ce sans incidence ?????
C'estsans doute pour cela que tu as besoin du sSR.path
SR est un objet "VB"
ta manip le transforme en objet "du FSO"
le pb est que tu le transmet ainsi comme variable VB as folder ( VB)
Ce serait plus clair si tu le laissait en variant pour qu'il ne change
pas de nature en cachette
En ce qui concerne mon script, il est sans mystère :
Je viens de tester son adaptation en VB6 ..;
pas de pb
je déclare les variables sans type ...
CDepart est le chemin de départ
' *************************
Dim FSO, FDepart, CDepart
Sub Vazi
Set FSO = CreateObject("Scripting.FileSystemObject")
Set FDepart = FSO.GetFolder(CDepart)
Call traite(FDepart)
End Sub
' ***************************
etc ...
' ****************************************
Sub traite(ByVal fd)
For Each sf in fd.Files
' test et traitement du "fichier" sf
' Attention c'est un objet hérité du FSO
' les propriétés et méthodes à utiliser en découlent...
' Sinon en passant par le Path on peut faire un objet
"natif" VB...
Next
For Each sfg in fd.SubFolders
Call traite(sfg)
Next
Euh, si tu pouvais me le refaire au ralenti, ça serait sympa :) _________________ bayosky a écrit :
Dans le message , Gloops a écrit :
Bonjour tout le monde,
Salut,
il faudrait voir sur le groupe scripting mais , justement j'ai fait un script récement qui balaye un répertoire de profondeur inconnu pour y rechercher et certains fichiers et je n'ai aucun pb ...
cela ressemble beaucoup à ce que tu proposes.. je ne vois pas trop l'avantage de objsousreps et le coup de getfolder(sr.path ) me semble bizarre L'avantage de la collection Subfolders est justement que l'on balaye les sous répertoires sans se préoccuper des chemins...
Ton Pb vient peut-être de l'objet Folder lui même :
Celui de VB : dans ta procédure : (ByVal Rep As Folder) et celui du FSO est-ce sans incidence ????? C'estsans doute pour cela que tu as besoin du sSR.path
SR est un objet "VB" ta manip le transforme en objet "du FSO"
le pb est que tu le transmet ainsi comme variable VB as folder ( VB)
Ce serait plus clair si tu le laissait en variant pour qu'il ne change pas de nature en cachette En ce qui concerne mon script, il est sans mystère : Je viens de tester son adaptation en VB6 ..;
pas de pb
je déclare les variables sans type ...
CDepart est le chemin de départ ' ************************* Dim FSO, FDepart, CDepart
Sub Vazi Set FSO = CreateObject("Scripting.FileSystemObject") Set FDepart = FSO.GetFolder(CDepart) Call traite(FDepart) End Sub ' ***************************
etc ...
' **************************************** Sub traite(ByVal fd)
For Each sf in fd.Files ' test et traitement du "fichier" sf ' Attention c'est un objet hérité du FSO ' les propriétés et méthodes à utiliser en découlent... ' Sinon en passant par le Path on peut faire un objet "natif" VB... Next For Each sfg in fd.SubFolders Call traite(sfg) Next
End Sub
Gloops
Fred a écrit :
For Each SR in objSousReps GereRepertoire fso.GetFolder(SR.path)
et GereRepertoire SR ?
Est-ce que je n'ai pas anticipé la question ? Mais peut-être effectivement ai-je eu tort finalement.
Mais là, me voilà pris d'un doute : j'ai cherché un fichier, et j'ai dû aller le prendre sur la source, il n'avait pas été copié.
Tu ne donnes pas le code de GèreFichier. L'erreur est peut-être dedans ? Un fichier verrouillé au moment de l'appel peut-être ?
Si je n'ai pas mis le code de GereFichier, c'est que cette fonction commence par une écriture dans le fichier d'historique, et que donc si je ne trouve pas un certain fichier mentionné dans ce fichier d'historique, c'est que GereFichier n'a pas été appelée pour ce fichier.
Enfin voilà la tête qu'elle a (Affiche envoie le texte vers la fenêtre de débogage et vers un fichier) : (Je vais toutefois refaire un test en vérifiant bien chkNonTraites, des fois que l'erreur soit dans ma tête.)
Sub GereFichier(ByVal Fic As File) Dim CheminCible As String On Error GoTo ErrGereFichier If (Form2.chkNonTraites = vbChecked) Then Affiche " " + Format(Fic.Size, "# ### ##0 ") + Fic.Name End If If (Form2.chkModifie = vbChecked) And (Fic.Attributes And Archive) = 0 _ And Not (Fic.Attributes And Volume) _ And Not (Fic.Attributes And Directory) Then
Exit Sub
End If NomFic = Right$(Fic.path, Len(Fic.path) - Len(DirSource) - 1) CheminCible = SepRep(DirCible) + NomFic Affiche "vers " + CheminCible DoEvents: Form1.Refresh: DoEvents Form1.lblTaille.Caption = Format(Fic.Size, "# ### ##0 ") Form1.lblDernier.Caption = Fic.Name DoEvents: Form1.Refresh: DoEvents Fic.Copy CheminCible Fic.Attributes = Fic.Attributes And Not Archive DoEvents: Form1.Refresh: DoEvents DoEvents Exit Sub ErrGereFichier: intErr = Err.Number strErr = Err.Description If intErr = 58 Then Resume End If
Affiche "Erreur sur traitement du fichier " + Fic.path + vbCrLf + Str$(intErr) + " : " + strErr, True If bArretErreurs Then MsgBox "Erreur sur traitement du fichier " + Fic.path + vbCr + Str$(intErr) + " : " + strErr End Sub
Fred a écrit :
For Each SR in objSousReps
GereRepertoire fso.GetFolder(SR.path)
et GereRepertoire SR ?
Est-ce que je n'ai pas anticipé la question ?
Mais peut-être effectivement ai-je eu tort finalement.
Mais là, me voilà pris d'un doute : j'ai cherché un fichier, et j'ai
dû aller le prendre sur la source, il n'avait pas été copié.
Tu ne donnes pas le code de GèreFichier. L'erreur est peut-être dedans ?
Un fichier verrouillé au moment de l'appel peut-être ?
Si je n'ai pas mis le code de GereFichier, c'est que cette fonction
commence par une écriture dans le fichier d'historique, et que donc si
je ne trouve pas un certain fichier mentionné dans ce fichier
d'historique, c'est que GereFichier n'a pas été appelée pour ce fichier.
Enfin voilà la tête qu'elle a (Affiche envoie le texte vers la fenêtre
de débogage et vers un fichier) :
(Je vais toutefois refaire un test en vérifiant bien chkNonTraites, des
fois que l'erreur soit dans ma tête.)
Sub GereFichier(ByVal Fic As File)
Dim CheminCible As String
On Error GoTo ErrGereFichier
If (Form2.chkNonTraites = vbChecked) Then
Affiche " " + Format(Fic.Size, "# ### ##0 ") + Fic.Name
End If
If (Form2.chkModifie = vbChecked) And (Fic.Attributes And Archive) = 0 _
And Not (Fic.Attributes And Volume) _
And Not (Fic.Attributes And Directory) Then
Exit Sub
End If
NomFic = Right$(Fic.path, Len(Fic.path) - Len(DirSource) - 1)
CheminCible = SepRep(DirCible) + NomFic
Affiche "vers " + CheminCible
DoEvents: Form1.Refresh: DoEvents
Form1.lblTaille.Caption = Format(Fic.Size, "# ### ##0 ")
Form1.lblDernier.Caption = Fic.Name
DoEvents: Form1.Refresh: DoEvents
Fic.Copy CheminCible
Fic.Attributes = Fic.Attributes And Not Archive
DoEvents: Form1.Refresh: DoEvents
DoEvents
Exit Sub
ErrGereFichier:
intErr = Err.Number
strErr = Err.Description
If intErr = 58 Then
Resume
End If
Affiche "Erreur sur traitement du fichier " + Fic.path + vbCrLf +
Str$(intErr) + " : " + strErr, True
If bArretErreurs Then MsgBox "Erreur sur traitement du fichier " +
Fic.path + vbCr + Str$(intErr) + " : " + strErr
End Sub
For Each SR in objSousReps GereRepertoire fso.GetFolder(SR.path)
et GereRepertoire SR ?
Est-ce que je n'ai pas anticipé la question ? Mais peut-être effectivement ai-je eu tort finalement.
Mais là, me voilà pris d'un doute : j'ai cherché un fichier, et j'ai dû aller le prendre sur la source, il n'avait pas été copié.
Tu ne donnes pas le code de GèreFichier. L'erreur est peut-être dedans ? Un fichier verrouillé au moment de l'appel peut-être ?
Si je n'ai pas mis le code de GereFichier, c'est que cette fonction commence par une écriture dans le fichier d'historique, et que donc si je ne trouve pas un certain fichier mentionné dans ce fichier d'historique, c'est que GereFichier n'a pas été appelée pour ce fichier.
Enfin voilà la tête qu'elle a (Affiche envoie le texte vers la fenêtre de débogage et vers un fichier) : (Je vais toutefois refaire un test en vérifiant bien chkNonTraites, des fois que l'erreur soit dans ma tête.)
Sub GereFichier(ByVal Fic As File) Dim CheminCible As String On Error GoTo ErrGereFichier If (Form2.chkNonTraites = vbChecked) Then Affiche " " + Format(Fic.Size, "# ### ##0 ") + Fic.Name End If If (Form2.chkModifie = vbChecked) And (Fic.Attributes And Archive) = 0 _ And Not (Fic.Attributes And Volume) _ And Not (Fic.Attributes And Directory) Then
Exit Sub
End If NomFic = Right$(Fic.path, Len(Fic.path) - Len(DirSource) - 1) CheminCible = SepRep(DirCible) + NomFic Affiche "vers " + CheminCible DoEvents: Form1.Refresh: DoEvents Form1.lblTaille.Caption = Format(Fic.Size, "# ### ##0 ") Form1.lblDernier.Caption = Fic.Name DoEvents: Form1.Refresh: DoEvents Fic.Copy CheminCible Fic.Attributes = Fic.Attributes And Not Archive DoEvents: Form1.Refresh: DoEvents DoEvents Exit Sub ErrGereFichier: intErr = Err.Number strErr = Err.Description If intErr = 58 Then Resume End If
Affiche "Erreur sur traitement du fichier " + Fic.path + vbCrLf + Str$(intErr) + " : " + strErr, True If bArretErreurs Then MsgBox "Erreur sur traitement du fichier " + Fic.path + vbCr + Str$(intErr) + " : " + strErr End Sub
Gloops
Salut Clive,
Je te dirai que j'ai pensé la même chose au sujet de XCOPY, que j'utilise depuis plus d'un an sur la machine précédente. J'ai essayé en mode sans échec, le résultat était le même.
Voir message id. , dans microsoft.public.fr.windowsxp le 6 mars à 16h20, "XCOPY : mémoire manquante".
A la suite de ça j'ai essayé Robocopy, qui m'avait l'air très bien, mais qui plus tard, au bout de quelques sauvegardes s'est mis à peiner.
Je l'ai désinstallé et réinstallé, ça n'a guère donné de résultat bien fameux.
D'où message id. du 9 mars à 1:26, "Blagues de Robocopy" (toujours dans microsoft.public.fr.windowsxp).
J'ai changé de machine parce que j'avais des soucis de ports USB, alors j'espère bien ne pas avoir les mêmes. J'ai des doutes sur l'adresse IP de la liaison sans fil, que je n'utilise d'ailleurs pas, mais si c'est ça ça va être dur d'être d'aplomb.
Avec mes copies sous VB, j'ai un peu de doutes sur l'exhaustivité de la sauvegarde, mais à la fin j'ai bien le message "Fin de traitement", et le temps de traitement paraît correct, et proportionnel à la taille de chaque fichier (que j'affiche sur le formulaire, histoire d'évaluer combien de temps le fichier doit rester en cours de traitement).
Si on trouve l'erreur pour XCOPY et Robocopy c'est tant mieux, sinon apparemment on arrivera à se débrouiller avec le programme VB.
Demain je vais faire vérifier le branchement du disque externe que j'ai utilisé, comme ça on saura si il y a un souci de ce côté.
J'aurais bien une autre question, je me demande si on peut limiter les ressources utilisées par le programme, histoire de ne pas trop ralentir d'autres applications quand on copie un très gros fichier, mais peut-être bien que ça serait plus clair si j'ouvrais un autre fil. D'ailleurs j'ai bien une idée, il faudrait copier le fichier par petits bouts, mais ça donnerait une syntaxe assez lourdingue il faut reconnaître, par rapport à Fichier.Copy cible.
____________________ Clive Lumb a écrit :
[un peu HS]
Que Robocopy ne marche pas m'étonne énormement. Je l'utilise (en version 2003) pour diverses applications, entre serveurs, sur des disques durs usb etc., jamais des problèmes de manque de ressources, jamais de traitement interrompu. Je serais tenté de soupçonner un problème ailleurs: de disque, driver ide, carte réseau etc.
Clive
Salut Clive,
Je te dirai que j'ai pensé la même chose au sujet de XCOPY, que
j'utilise depuis plus d'un an sur la machine précédente.
J'ai essayé en mode sans échec, le résultat était le même.
Voir message id. OjgjCGTQGHA.2496@TK2MSFTNGP11.phx.gbl, dans
microsoft.public.fr.windowsxp le 6 mars à 16h20, "XCOPY : mémoire
manquante".
A la suite de ça j'ai essayé Robocopy, qui m'avait l'air très bien, mais
qui plus tard, au bout de quelques sauvegardes s'est mis à peiner.
Je l'ai désinstallé et réinstallé, ça n'a guère donné de résultat bien
fameux.
D'où message id. elZuPAxQGHA.516@TK2MSFTNGP15.phx.gbl du 9 mars à 1:26,
"Blagues de Robocopy" (toujours dans microsoft.public.fr.windowsxp).
J'ai changé de machine parce que j'avais des soucis de ports USB, alors
j'espère bien ne pas avoir les mêmes. J'ai des doutes sur l'adresse IP
de la liaison sans fil, que je n'utilise d'ailleurs pas, mais si c'est
ça ça va être dur d'être d'aplomb.
Avec mes copies sous VB, j'ai un peu de doutes sur l'exhaustivité de la
sauvegarde, mais à la fin j'ai bien le message "Fin de traitement", et
le temps de traitement paraît correct, et proportionnel à la taille de
chaque fichier (que j'affiche sur le formulaire, histoire d'évaluer
combien de temps le fichier doit rester en cours de traitement).
Si on trouve l'erreur pour XCOPY et Robocopy c'est tant mieux, sinon
apparemment on arrivera à se débrouiller avec le programme VB.
Demain je vais faire vérifier le branchement du disque externe que j'ai
utilisé, comme ça on saura si il y a un souci de ce côté.
J'aurais bien une autre question, je me demande si on peut limiter les
ressources utilisées par le programme, histoire de ne pas trop ralentir
d'autres applications quand on copie un très gros fichier, mais
peut-être bien que ça serait plus clair si j'ouvrais un autre fil.
D'ailleurs j'ai bien une idée, il faudrait copier le fichier par petits
bouts, mais ça donnerait une syntaxe assez lourdingue il faut
reconnaître, par rapport à Fichier.Copy cible.
____________________
Clive Lumb a écrit :
[un peu HS]
Que Robocopy ne marche pas m'étonne énormement.
Je l'utilise (en version 2003) pour diverses applications, entre serveurs,
sur des disques durs usb etc., jamais des problèmes de manque de ressources,
jamais de traitement interrompu.
Je serais tenté de soupçonner un problème ailleurs: de disque, driver ide,
carte réseau etc.
Je te dirai que j'ai pensé la même chose au sujet de XCOPY, que j'utilise depuis plus d'un an sur la machine précédente. J'ai essayé en mode sans échec, le résultat était le même.
Voir message id. , dans microsoft.public.fr.windowsxp le 6 mars à 16h20, "XCOPY : mémoire manquante".
A la suite de ça j'ai essayé Robocopy, qui m'avait l'air très bien, mais qui plus tard, au bout de quelques sauvegardes s'est mis à peiner.
Je l'ai désinstallé et réinstallé, ça n'a guère donné de résultat bien fameux.
D'où message id. du 9 mars à 1:26, "Blagues de Robocopy" (toujours dans microsoft.public.fr.windowsxp).
J'ai changé de machine parce que j'avais des soucis de ports USB, alors j'espère bien ne pas avoir les mêmes. J'ai des doutes sur l'adresse IP de la liaison sans fil, que je n'utilise d'ailleurs pas, mais si c'est ça ça va être dur d'être d'aplomb.
Avec mes copies sous VB, j'ai un peu de doutes sur l'exhaustivité de la sauvegarde, mais à la fin j'ai bien le message "Fin de traitement", et le temps de traitement paraît correct, et proportionnel à la taille de chaque fichier (que j'affiche sur le formulaire, histoire d'évaluer combien de temps le fichier doit rester en cours de traitement).
Si on trouve l'erreur pour XCOPY et Robocopy c'est tant mieux, sinon apparemment on arrivera à se débrouiller avec le programme VB.
Demain je vais faire vérifier le branchement du disque externe que j'ai utilisé, comme ça on saura si il y a un souci de ce côté.
J'aurais bien une autre question, je me demande si on peut limiter les ressources utilisées par le programme, histoire de ne pas trop ralentir d'autres applications quand on copie un très gros fichier, mais peut-être bien que ça serait plus clair si j'ouvrais un autre fil. D'ailleurs j'ai bien une idée, il faudrait copier le fichier par petits bouts, mais ça donnerait une syntaxe assez lourdingue il faut reconnaître, par rapport à Fichier.Copy cible.
____________________ Clive Lumb a écrit :
[un peu HS]
Que Robocopy ne marche pas m'étonne énormement. Je l'utilise (en version 2003) pour diverses applications, entre serveurs, sur des disques durs usb etc., jamais des problèmes de manque de ressources, jamais de traitement interrompu. Je serais tenté de soupçonner un problème ailleurs: de disque, driver ide, carte réseau etc.
Clive
Gloops
Clive Lumb a écrit :
Il y a un très bon exemple dans l'API Guide sous "GetFileAttributes" dont tu pourrais t'inspirer. Cela utilise la recursivité à fond. C'est assez rapide aussi.
Clive
L'exemple FindFiles ?
Il faudra que je regarde ça, merci.
Clive Lumb a écrit :
Il y a un très bon exemple dans l'API Guide sous "GetFileAttributes" dont tu
pourrais t'inspirer. Cela utilise la recursivité à fond.
C'est assez rapide aussi.
Il y a un très bon exemple dans l'API Guide sous "GetFileAttributes" dont tu pourrais t'inspirer. Cela utilise la recursivité à fond. C'est assez rapide aussi.
Clive
L'exemple FindFiles ?
Il faudra que je regarde ça, merci.
Clive Lumb
Gloops wrote:
Clive Lumb a écrit :
[un peu HS]
Que Robocopy ne marche pas m'étonne énormement. Je l'utilise (en version 2003) pour diverses applications, entre serveurs, sur des disques durs usb etc., jamais des problèmes de manque de ressources, jamais de traitement interrompu. Je serais tenté de soupçonner un problème ailleurs: de disque, driver ide, carte réseau etc.
Clive
Salut Clive,
Je te dirai que j'ai pensé la même chose au sujet de XCOPY, que j'utilise depuis plus d'un an sur la machine précédente. J'ai essayé en mode sans échec, le résultat était le même.
Voir message id. , dans microsoft.public.fr.windowsxp le 6 mars à 16h20, "XCOPY : mémoire manquante".
A la suite de ça j'ai essayé Robocopy, qui m'avait l'air très bien, mais qui plus tard, au bout de quelques sauvegardes s'est mis à peiner.
Je l'ai désinstallé et réinstallé, ça n'a guère donné de résultat bien fameux.
D'où message id. du 9 mars à 1:26, "Blagues de Robocopy" (toujours dans microsoft.public.fr.windowsxp).
J'ai changé de machine parce que j'avais des soucis de ports USB, alors j'espère bien ne pas avoir les mêmes. J'ai des doutes sur l'adresse IP de la liaison sans fil, que je n'utilise d'ailleurs pas, mais si c'est ça ça va être dur d'être d'aplomb.
Avec mes copies sous VB, j'ai un peu de doutes sur l'exhaustivité de la sauvegarde, mais à la fin j'ai bien le message "Fin de traitement", et le temps de traitement paraît correct, et proportionnel à la taille de chaque fichier (que j'affiche sur le formulaire, histoire d'évaluer combien de temps le fichier doit rester en cours de traitement).
Si on trouve l'erreur pour XCOPY et Robocopy c'est tant mieux, sinon apparemment on arrivera à se débrouiller avec le programme VB.
Demain je vais faire vérifier le branchement du disque externe que j'ai utilisé, comme ça on saura si il y a un souci de ce côté.
J'aurais bien une autre question, je me demande si on peut limiter les ressources utilisées par le programme, histoire de ne pas trop ralentir d'autres applications quand on copie un très gros fichier, mais peut-être bien que ça serait plus clair si j'ouvrais un autre fil. D'ailleurs j'ai bien une idée, il faudrait copier le fichier par petits bouts, mais ça donnerait une syntaxe assez lourdingue il faut reconnaître, par rapport à Fichier.Copy cible.
D'abord j'utilise la version 10 de Robocopy, tu pourras le télécharger avec la doc ici: http://clumb.free.fr/robocopy.zip
La ligne de commande (en fichier bat) "kivabien" pour moi est reproduit en fin de post
On peut utiliser l'option /IPG:n où "n" est un delai en millisecondes entre paquets de 64k - si ton disque/système a des problèmes pour suivre cela pourrait être utile.
Toutefois Xcopy et Robocopy utilisent les fonctions de base de Windows pour copier les fichiers - en consequence ils devraient être très très fiables et devraient gèrer les erreurs, disques lents etc. sans le moindre problème. Si tu as des problèmes de manque de memoire/plantage il faut soupçonner un problème ailleurs. Outre des histoires de driver, chipset ide etc. déjà évoquées, je me demande si ce n'est pas un autre programme qui tourne qui pourrait être la source du problème. - Tu n'auras pas quelquechose qui regarde l'usage des fichiers comme filemon ou diskmon de Sysinternals ? - Ton anti-virus aussi pourrait "exploser" si tu fait trop d'actions disque pour lui (je parle des AVALC - "anti-virus à la con" tels que NOD), essayer de désactiver le scan en temps réel pendant la copie. - Service indexation activé sur le disque destination ? Cela pourrait poser un problème. - Disque USB et modem ADSL USB sur la même interface ? - Disque USB 2.5" auto-alimenté par l'USB ? - Chipset VIA ancienne génération ?
Voilà
Clive
:: Lancer le bat à partir du disque DESTINATION ::Il trouvera tout seul la lettre de ce disque
:: Trouver la lettre du disque destination Set DriveLet=%~d0
:: Chemin vers Robocopy. Set Roboloc=%DriveLet%RobocopyCommandsRoboScripRobocopy.exe
:: Chemin de base pour les fichiers log. Set OutputDir=%DriveLet%RobocopyCommandsRoboLogs
:: Chemin de base pour les sauvegardes. Set DestSrvr=%DriveLet%Backup
::Chemin pour le repertoire (et sous repertoires) à sauvegarder Set Source=%HOMEDRIVE%%HOMEPATH%Mes Documents
::Nom du fichier log pour ce sauvegarde Set LogName=MesDocsLog.txt
::Chemin vers le fichier log Set LogLoc=%OutputDir%%LogName%
:: Mettre une des lignes suivant en "remarque" selon le type de sauvgarde (miroir ou addtif)
::Copie additive (conserve tous les fichiers sur la destination, même s'ils n'existent plus sur la source) : "%ROBOLOC%" "%Source%" "%DestSrvr%MesDocs" /E /ZB /TEE /COPY:DAT /R:1 /W:1 /LOG+:"%LogLoc%"
::Copie "Miroir" (efface les fichiers sur la destination s'ils n'existent plus sur la source) : :: "%ROBOLOC%" "%Source%" "%DestSrvr%MesDocs" /MIR /ZB /TEE /COPY:DAT /R:1 /W:1 /LOG+:"%LogLoc%"
:: Afficher le résultat call notepad "%LogLoc%" Goto :EOF
Gloops wrote:
Clive Lumb a écrit :
[un peu HS]
Que Robocopy ne marche pas m'étonne énormement.
Je l'utilise (en version 2003) pour diverses applications, entre
serveurs, sur des disques durs usb etc., jamais des problèmes de
manque de ressources, jamais de traitement interrompu.
Je serais tenté de soupçonner un problème ailleurs: de disque,
driver ide, carte réseau etc.
Clive
Salut Clive,
Je te dirai que j'ai pensé la même chose au sujet de XCOPY, que
j'utilise depuis plus d'un an sur la machine précédente.
J'ai essayé en mode sans échec, le résultat était le même.
Voir message id. OjgjCGTQGHA.2496@TK2MSFTNGP11.phx.gbl, dans
microsoft.public.fr.windowsxp le 6 mars à 16h20, "XCOPY : mémoire
manquante".
A la suite de ça j'ai essayé Robocopy, qui m'avait l'air très bien,
mais qui plus tard, au bout de quelques sauvegardes s'est mis à
peiner.
Je l'ai désinstallé et réinstallé, ça n'a guère donné de résultat bien
fameux.
D'où message id. elZuPAxQGHA.516@TK2MSFTNGP15.phx.gbl du 9 mars à
1:26, "Blagues de Robocopy" (toujours dans
microsoft.public.fr.windowsxp).
J'ai changé de machine parce que j'avais des soucis de ports USB,
alors j'espère bien ne pas avoir les mêmes. J'ai des doutes sur
l'adresse IP de la liaison sans fil, que je n'utilise d'ailleurs pas,
mais si c'est ça ça va être dur d'être d'aplomb.
Avec mes copies sous VB, j'ai un peu de doutes sur l'exhaustivité de
la sauvegarde, mais à la fin j'ai bien le message "Fin de
traitement", et le temps de traitement paraît correct, et
proportionnel à la taille de chaque fichier (que j'affiche sur le
formulaire, histoire d'évaluer combien de temps le fichier doit
rester en cours de traitement).
Si on trouve l'erreur pour XCOPY et Robocopy c'est tant mieux, sinon
apparemment on arrivera à se débrouiller avec le programme VB.
Demain je vais faire vérifier le branchement du disque externe que
j'ai utilisé, comme ça on saura si il y a un souci de ce côté.
J'aurais bien une autre question, je me demande si on peut limiter les
ressources utilisées par le programme, histoire de ne pas trop
ralentir d'autres applications quand on copie un très gros fichier,
mais peut-être bien que ça serait plus clair si j'ouvrais un autre
fil. D'ailleurs j'ai bien une idée, il faudrait copier le fichier par
petits bouts, mais ça donnerait une syntaxe assez lourdingue il faut
reconnaître, par rapport à Fichier.Copy cible.
D'abord j'utilise la version 10 de Robocopy, tu pourras le télécharger avec
la doc ici:
http://clumb.free.fr/robocopy.zip
La ligne de commande (en fichier bat) "kivabien" pour moi est reproduit en
fin de post
On peut utiliser l'option /IPG:n où "n" est un delai en millisecondes entre
paquets de 64k - si ton disque/système a des problèmes pour suivre cela
pourrait être utile.
Toutefois Xcopy et Robocopy utilisent les fonctions de base de Windows pour
copier les fichiers - en consequence ils devraient être très très fiables et
devraient gèrer les erreurs, disques lents etc. sans le moindre problème. Si
tu as des problèmes de manque de memoire/plantage il faut soupçonner un
problème ailleurs. Outre des histoires de driver, chipset ide etc. déjà
évoquées, je me demande si ce n'est pas un autre programme qui tourne qui
pourrait être la source du problème.
- Tu n'auras pas quelquechose qui regarde l'usage des fichiers comme filemon
ou diskmon de Sysinternals ?
- Ton anti-virus aussi pourrait "exploser" si tu fait trop d'actions disque
pour lui (je parle des AVALC - "anti-virus à la con" tels que NOD), essayer
de désactiver le scan en temps réel pendant la copie.
- Service indexation activé sur le disque destination ? Cela pourrait poser
un problème.
- Disque USB et modem ADSL USB sur la même interface ?
- Disque USB 2.5" auto-alimenté par l'USB ?
- Chipset VIA ancienne génération ?
Voilà
Clive
:: Lancer le bat à partir du disque DESTINATION
::Il trouvera tout seul la lettre de ce disque
:: Trouver la lettre du disque destination
Set DriveLet=%~d0
:: Chemin vers Robocopy.
Set Roboloc=%DriveLet%RobocopyCommandsRoboScripRobocopy.exe
:: Chemin de base pour les fichiers log.
Set OutputDir=%DriveLet%RobocopyCommandsRoboLogs
:: Chemin de base pour les sauvegardes.
Set DestSrvr=%DriveLet%Backup
::Chemin pour le repertoire (et sous repertoires) à sauvegarder
Set Source=%HOMEDRIVE%%HOMEPATH%Mes Documents
::Nom du fichier log pour ce sauvegarde
Set LogName=MesDocsLog.txt
::Chemin vers le fichier log
Set LogLoc=%OutputDir%%LogName%
:: Mettre une des lignes suivant en "remarque" selon le type de sauvgarde
(miroir ou addtif)
::Copie additive (conserve tous les fichiers sur la destination, même s'ils
n'existent plus sur la source) :
"%ROBOLOC%" "%Source%" "%DestSrvr%MesDocs" /E /ZB /TEE /COPY:DAT /R:1 /W:1
/LOG+:"%LogLoc%"
::Copie "Miroir" (efface les fichiers sur la destination s'ils n'existent
plus sur la source) :
:: "%ROBOLOC%" "%Source%" "%DestSrvr%MesDocs" /MIR /ZB /TEE /COPY:DAT /R:1
/W:1 /LOG+:"%LogLoc%"
:: Afficher le résultat
call notepad "%LogLoc%"
Goto :EOF
Que Robocopy ne marche pas m'étonne énormement. Je l'utilise (en version 2003) pour diverses applications, entre serveurs, sur des disques durs usb etc., jamais des problèmes de manque de ressources, jamais de traitement interrompu. Je serais tenté de soupçonner un problème ailleurs: de disque, driver ide, carte réseau etc.
Clive
Salut Clive,
Je te dirai que j'ai pensé la même chose au sujet de XCOPY, que j'utilise depuis plus d'un an sur la machine précédente. J'ai essayé en mode sans échec, le résultat était le même.
Voir message id. , dans microsoft.public.fr.windowsxp le 6 mars à 16h20, "XCOPY : mémoire manquante".
A la suite de ça j'ai essayé Robocopy, qui m'avait l'air très bien, mais qui plus tard, au bout de quelques sauvegardes s'est mis à peiner.
Je l'ai désinstallé et réinstallé, ça n'a guère donné de résultat bien fameux.
D'où message id. du 9 mars à 1:26, "Blagues de Robocopy" (toujours dans microsoft.public.fr.windowsxp).
J'ai changé de machine parce que j'avais des soucis de ports USB, alors j'espère bien ne pas avoir les mêmes. J'ai des doutes sur l'adresse IP de la liaison sans fil, que je n'utilise d'ailleurs pas, mais si c'est ça ça va être dur d'être d'aplomb.
Avec mes copies sous VB, j'ai un peu de doutes sur l'exhaustivité de la sauvegarde, mais à la fin j'ai bien le message "Fin de traitement", et le temps de traitement paraît correct, et proportionnel à la taille de chaque fichier (que j'affiche sur le formulaire, histoire d'évaluer combien de temps le fichier doit rester en cours de traitement).
Si on trouve l'erreur pour XCOPY et Robocopy c'est tant mieux, sinon apparemment on arrivera à se débrouiller avec le programme VB.
Demain je vais faire vérifier le branchement du disque externe que j'ai utilisé, comme ça on saura si il y a un souci de ce côté.
J'aurais bien une autre question, je me demande si on peut limiter les ressources utilisées par le programme, histoire de ne pas trop ralentir d'autres applications quand on copie un très gros fichier, mais peut-être bien que ça serait plus clair si j'ouvrais un autre fil. D'ailleurs j'ai bien une idée, il faudrait copier le fichier par petits bouts, mais ça donnerait une syntaxe assez lourdingue il faut reconnaître, par rapport à Fichier.Copy cible.
D'abord j'utilise la version 10 de Robocopy, tu pourras le télécharger avec la doc ici: http://clumb.free.fr/robocopy.zip
La ligne de commande (en fichier bat) "kivabien" pour moi est reproduit en fin de post
On peut utiliser l'option /IPG:n où "n" est un delai en millisecondes entre paquets de 64k - si ton disque/système a des problèmes pour suivre cela pourrait être utile.
Toutefois Xcopy et Robocopy utilisent les fonctions de base de Windows pour copier les fichiers - en consequence ils devraient être très très fiables et devraient gèrer les erreurs, disques lents etc. sans le moindre problème. Si tu as des problèmes de manque de memoire/plantage il faut soupçonner un problème ailleurs. Outre des histoires de driver, chipset ide etc. déjà évoquées, je me demande si ce n'est pas un autre programme qui tourne qui pourrait être la source du problème. - Tu n'auras pas quelquechose qui regarde l'usage des fichiers comme filemon ou diskmon de Sysinternals ? - Ton anti-virus aussi pourrait "exploser" si tu fait trop d'actions disque pour lui (je parle des AVALC - "anti-virus à la con" tels que NOD), essayer de désactiver le scan en temps réel pendant la copie. - Service indexation activé sur le disque destination ? Cela pourrait poser un problème. - Disque USB et modem ADSL USB sur la même interface ? - Disque USB 2.5" auto-alimenté par l'USB ? - Chipset VIA ancienne génération ?
Voilà
Clive
:: Lancer le bat à partir du disque DESTINATION ::Il trouvera tout seul la lettre de ce disque
:: Trouver la lettre du disque destination Set DriveLet=%~d0
:: Chemin vers Robocopy. Set Roboloc=%DriveLet%RobocopyCommandsRoboScripRobocopy.exe
:: Chemin de base pour les fichiers log. Set OutputDir=%DriveLet%RobocopyCommandsRoboLogs
:: Chemin de base pour les sauvegardes. Set DestSrvr=%DriveLet%Backup
::Chemin pour le repertoire (et sous repertoires) à sauvegarder Set Source=%HOMEDRIVE%%HOMEPATH%Mes Documents
::Nom du fichier log pour ce sauvegarde Set LogName=MesDocsLog.txt
::Chemin vers le fichier log Set LogLoc=%OutputDir%%LogName%
:: Mettre une des lignes suivant en "remarque" selon le type de sauvgarde (miroir ou addtif)
::Copie additive (conserve tous les fichiers sur la destination, même s'ils n'existent plus sur la source) : "%ROBOLOC%" "%Source%" "%DestSrvr%MesDocs" /E /ZB /TEE /COPY:DAT /R:1 /W:1 /LOG+:"%LogLoc%"
::Copie "Miroir" (efface les fichiers sur la destination s'ils n'existent plus sur la source) : :: "%ROBOLOC%" "%Source%" "%DestSrvr%MesDocs" /MIR /ZB /TEE /COPY:DAT /R:1 /W:1 /LOG+:"%LogLoc%"
:: Afficher le résultat call notepad "%LogLoc%" Goto :EOF
Clive Lumb
Note: Dans mon post ci-dessus, les lignes du fichier bat qui commencent avec ">>" devrait commencer par deux fois ":" C'est mon lecteur de news qui a pris les "::" pour des quotes
Afficher le résultat
call notepad "%LogLoc%" Goto :EOF
Note:
Dans mon post ci-dessus, les lignes du fichier bat qui commencent avec ">>"
devrait commencer par deux fois ":"
C'est mon lecteur de news qui a pris les "::" pour des quotes
Note: Dans mon post ci-dessus, les lignes du fichier bat qui commencent avec ">>" devrait commencer par deux fois ":" C'est mon lecteur de news qui a pris les "::" pour des quotes
