False Message d'erreur 'Sharing Violation' Xcopy
J'exécute un script batch (sur l'ordinateur A). Le script copie plusieurs fichiers d’un autre ordinateur (ordinateur B). Lorsque le script de traitement par lots est exécuté, il indique qu’il est impossible de copier certains fichiers de l’ordinateur B dans ses propres répertoires en raison de «Partage des violations».
En lisant d'autres pages stackoverflow, je constate que cela se produit lorsqu'un autre programme a le fichier verrouillé (un autre programme utilise/accède au fichier). Cependant, je peux accéder à l’ordinateur B et supprimer le fichier dont l’ordinateur A prétendait avoir été verrouillé (en raison de violations de partage).
La seule chose que je puisse imaginer est peut-être que le script de traitement par lots sur l'ordinateur A verrouille le fichier (d'une manière ou d'une autre) au cours d'une commande antérieure et que cette commande antérieure définit le verrouillage du fichier. Mais je pense que les commandes de script batch sont exécutées en série, sauf indication contraire.
Quelqu'un at-il déjà eu ce problème auparavant? Le script copierait avec succès sans partager les violations il y a environ une semaine ou deux. Aucun changement n'est survenu dans le script.
Après beaucoup d'essais et d'erreurs, j'ai pu déterminer pourquoi je recevais une violation partagée.
Je copiais des fichiers de l'ordinateur B à l'ordinateur A
Je pensais que les violations de partage se produisaient car l'ordinateur B ne me permettait pas de copier ces fichiers [stockés sur son disque dur].
En réalité, le répertoire de l’ordinateur A (copie sur ordinateur) contient des fichiers sur lesquels je ne peux pas écrire. C'est pourquoi j'ai eu la violation partagée.
L'un des fichiers du répertoire de l'ordinateur A était une tâche exécutable qui, je pensais, avait été supprimée (taskkill). Cependant, cet exécutable a été oublié dans le processus taskkill (en fait, il n’a pas été répertorié dans le gestionnaire de tâches) et le programme était toujours en cours d’exécution (le fichier était en cours d’utilisation). Par conséquent, lorsque j'ai essayé d'écraser le fichier, xcopy s'est vu refuser l'accès pour écraser ce fichier/cet exécutable, ce qui a entraîné des violations partagées.
J'avais l'impression que les violations de partage ne se produiraient pendant xcopy que si les fichiers de l'ordinateur B ne permettaient pas la copie.
La plupart du temps, vous avez ce problème car un autre programme exécutable (exe) utilise en quelque sorte les fichiers que vous souhaitez copier. Tuez simplement le programme en utilisant le gestionnaire de tâches et la copie fonctionnera.
J'ai rencontré le même problème avec xcopy dans un fichier de commandes et j'ai découvert que l'attribut Lecture seule du fichier à l'origine de la violation de partage était défini. La suppression de l'attribut Lecture seule a permis la copie du fichier.
Je dois noter que j’utilisais déjà le commutateur/R avec xcopy pour autoriser l’écrasement des fichiers en lecture seule. J'ai également découvert que le fichier se trouvait déjà dans le dossier de destination avec l'attribut Lecture seule. Il semble que la lecture seule ait été réinitialisée sur le fichier cible après qu'il a été copié avec succès. J'ai encore besoin d'enquêter plus loin. Le commutateur/K peut empêcher cela.
Il convient également de noter que mon fichier de commandes contient une série d'instructions xcopy. La violation de partage a bloqué la première ligne, mais a permis au fichier de commandes de continuer sur les lignes xcopy suivantes. L'erreur se produisait de manière inaperçue depuis un certain temps, le message de violation de partage s'étant déroulé hors de l'écran. Je pourrais aussi essayer d’utiliser le commutateur/C pour continuer à copier même en cas d’erreur.
J'espère que cela pourra aider d'autres personnes qui rencontrent ce problème.
Parfois, un fichier/répertoire peut être temporairement indisponible/verrouillé par un autre processus. Si votre programme de traitement par lots essaie de copier à ce moment, cela provoquera une "erreur inconnue/violation partagée".
L'utilisation de robocopy au lieu de "xcopy/copy" peut être plus pertinente dans ce cas, car elle n'échoue pas immédiatement, mais réessaie plusieurs fois avant d'échouer.
Pour moi, cela s'est produit lorsque j'ai tenté de copier un fichier war dans un répertoire Tomcat. Je vérifiais sans cesse que Tomcat était arrêté. Le problème était que j'avais le fichier de guerre ouvert dans 7Zip pendant que j'examinais le contenu. J'ai fermé 7Zip et les problèmes quand je suis parti.
Évident maintenant, pas tellement quand cela se produisait.
J'ai rencontré le même problème ... Le fichier problématique était une feuille Excel. Le problème était dû au fait que mon collègue avait ouvert le fichier que je voulais copier. Il est bon de mentionner que je copie des données de ma station dans le dossier partagé. Donc, xcopy ne peut pas le remplacer.
Le commutateur /C a résolu le problème pour moi. Xcopy a ensuite ignoré les fichiers ouverts par d'autres programmes et s'est poursuivi.