11.05.2017

9154

RoboCopy Log Fehler?

Hallo liebe Administratoren,

Bin heute auf ein komisches Problem gestoßen.

Folgender Code:

robocopy "C:\." NULL "*.*"  /l /s /ndl /xx /np /nc /ns /njh /njs /fp /unilog:"%cd%\log.txt" /mt 5 /xd "*windows*"  

by rubberman

Das Problem:

Normalerweise sollte das Log das erzeugt wird so aussehen:

   File1
   File2
   File3

Jetzt sieht er aber so aus...:

Das ist sehr unpraktisch.
Nach Google suche hab ich herausgefunden das dies nicht passiert wenn man mit dem aktuellen Ordner in C:\ ( oder vergleichbar ) ist, ansonsten wird das Log zu diesem Müll oben.
Da ich das Log weiterverarbeiten möchte, ist der aktuelle Status der Ausgabe unbrauchbar.

Weiß da jemand was?

Ganz nebenbei in der Windows 7 Version von RoboCopy ist das Unilog nur
chinesische Zeichen durch einen Bug. Falls dazu jemand eine Lösung weiß wäre ich unendlich dankbar.

Einen schönen Abend noch allerseits.

~ clragon

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 337517

Url: https://administrator.de/contentid/337517

Ausgedruckt am: 07.11.2024 um 21:11 Uhr

16 Kommentare

Neuester Kommentar

Hallo,

mit welchem Editor machst Du das denn auf? Kann der überhaupt Unicode?

Gruß,
Jörg

Hallo,

Zitat von @130834:
Bin heute auf ein komisches Problem gestoßen.

Kopf wohl leer

Normalerweise sollte das Log das erzeugt wird so aussehen:

Wird es ja.
Nur die Art wie ein Waagenrücklauf und Zeilenvorschub Interpretiert wird ist je nach OS sehr unterschiedlich. Dein Windows braucht im Editor zwingend seine 0D 0As. Dein Wordpad geht damit schon wieder anders um. Nimm mal Wordpad. Dein Parameter UniLog ist der Schuldige.

Da ich das Log weiterverarbeiten möchte, ist der aktuelle Status der Ausgabe unbrauchbar.

Fragt sich womit du das weiterverarbeiten willst. Was macht das mit den nicht druckbaren Zeichen wie ein 0D 0A (Carriage Return, Line Feed)? Schau dir mal deine Datei in einen Hex Editor oder Notepad++ an und vergleiche wenn du das Log ohne UniLog speicherst.

Weiß da jemand was?

Click. Turn brian on before guessing

Ganz nebenbei in der Windows 7 Version von RoboCopy ist das Unilog nur chinesische Zeichen durch einen Bug. Falls dazu jemand eine Lösung weiß wäre ich unendlich dankbar.

Robocopy in Powershell ausführen.

robocopy "C:\." NULL "*.*" |out-file "WasImmerDuWillst.log"  

Gruß,
Peter

[Nachtrag]
Der Ordner NULL wird natürlich angelegt. Umleitung zu NUL liefert Fehler 53 Zugriff auf Zielverzehniss \\.\NUL\ Der Netzwerkpfad wurde nicht gefunden...
[/Nachtrag]

Hallo,

Schau Dir das Log mal mit NotePad++ an. Hilft ungemein.

Und dann setzt Du noch explizit die Option /MT ein. Das kann ein Logfile schon mal verwurschteln, sprich die Logeintraege einfach so hintereinander schreiben.

BFF

Zitat von @130834:

Hallo liebe Administratoren,

Bin heute auf ein komisches Problem gestoßen.

Folgender Code:

robocopy "C:\." NULL "*.*"  /l /s /ndl /xx /np /nc /ns /njh /njs /fp /unilog:"%cd%\log.txt" /mt 5 /xd "*windows*"  
> 

by rubberman

Ähm Frage: heißt das nicht NUL? Wie ich würde jetzt mal davon ausgehen, Du legst eine Datei namens NULL an.
Wenn das so gewollt ist.

[Edith] Habe es gerade unter WIN 10 (Build 1607) ausprobiert. Und hier wird die Datei mit dem Notepad korrekt angelegt und angezeigt.

Gruss Penny.

Ähm Frage: heißt das nicht NUL? Wie ich würde jetzt mal davon ausgehen, Du legst eine Datei namens NULL an.

Hab ja nur darauf gewartet, dass jemand drüber stolpert

Es geht nicht darum irgend etwas zu kopieren, sondern nur um die Ausgabe, die weiterverarbeitet wird. Es wird also nichts angelegt/kopiert (Option /L). NUL wird von robocopy an dieser Stelle nicht akzeptiert. NULL ist ein Workaround, der aber voraussetzt, dass es kein Verzeichnis (mit Inhalt) namens NULL im Arbeitsverzeichnis gibt. Zur Not könnte man auch vorher einen zufälligen Name per %random% generieren und das in eine Prüfschleife packen um sicher zu stellen, dass es kein Verzeichnis mit diesem Name gibt ...

Schau mir das heute Abend mal an.
@130834 den "chinesische Zeichen Bug" werde ich vermutlich nicht nachstellen können. Öffne die Datei in einem HEX Editor und mach mal ein Screenshot vom Dateianfang. Vielleicht findet sich die Ursache und ein Workaround.

Grüße
rubberman

Der "chinesische Zeichen Bug" ( obwohl ich nicht einmal weiß ob es Chinesisch ist ) entsteht wenn man den /unilog Parameter in Windows 7 verwendet. In der Windows 10 robocopy wurde er gefixt, diese ist aber nicht offenbar rückwärts kompatible und somit wird Unilog in Windows 7 komplett nutzlos, zumindest soweit wie ich das sehen konnte. Man kann dies ganz einfach testen in dem man eine Windows 7 robocopy.exe in Windows 10 verwendet.

Die Zeichen sehen so aus

Im Hex Editor so

Und hier wäre dann noch das kaputte (?) Log im Hex Editor
Oh... ich kann den Bug nicht reproduzieren.... Ich fühl mich grad veräppelt...
Gestern hat jedes Log außer die mit dem Arbeitsordner C:\ ( als aktueller CMD Ordner ) wie der Schrott da oben im Bild ausgesehen,
heute ist wieder alles gut, werde ich hier irgendwie auf den Arm genommen?
Das ist noch viel schlimmer. wenn ich den Bug nicht reproduzieren kann, kann ich nicht wissen wann er auftritt, na ganz toll.
Tut mir leid, ich teste mal rum bis ich ihn wieder gefunden hab.... Vielleicht finde ich dabei ja sogar die Ursache

EDIT: habs herausgefunden. Jetzt weiss ich es. Kopiert man die Windows 10 robocopy aus System32 und verwendet sie allein anstatt der System exe, wird dieses gewurschtel erzeugt. nur; warum?

lg clragon

EDIT: PS: Entfernt man die ersten beiden Zeichen des Chinesischen Logs sieht es plötzlich so aus. Nur... warum ist es sooo Langsam und loggt dabei auch noch Zugriff verweigert....?

Der Ordner NULL wird natürlich angelegt. Umleitung zu NUL liefert Fehler 53 Zugriff auf Zielverzehniss \\.\NUL\ Der Netzwerkpfad wurde nicht gefunden...

Kann mit /l verhindert werden

Robocopy in Powershell ausführen.

Nur benutze ich kein powershell in meinen Skripten aus 3 einfachen Gründen;

1. Der Rest des Skriptes ist in Batch
2. Ich weiß nicht wie man Powershell Befehle in Batch ausführt
3. Powershell braucht so lange allein zum Aufstarten das es dem ausführen eines ganzen Batch Skripts Konkurrenz macht.

Fragt sich womit du das weiterverarbeiten willst

Mit Batch

Kopf wohl leer

Vielleicht ist mein Kopf ja mit anderen Dingen gefüllt

Click. Turn brian on before guessing

Bevor ich im Forum um Hilfe Frage teste, recherchiere und überlege ich, bis ich mir sicher bin das ich Hilfe brauche.
Ich denke mein Gehirn ( brian, jaja ) wahr auf jeden Fall an, aber danke für die Sorge.

Schau dir mal deine Datei in einen Hex Editor oder Notepad++ an und vergleiche wenn du das Log ohne UniLog speicherst.

Das ist eine sehr gute Idee, ich habe aber bereits schon herausgefunden das es nicht an der unilog Funktion liegt,
welche in Windows 10 ( erstaunlicherweise ) vollständig funktionstüchtig ist. Trotzdem danke

lg clragon

Hallo,

Setze mal den Papierkorb als ausgeschlossenen Ordner. Und schau nach anderen temporaeren zum ausschliessen.

Es macht keinen Sinn die zu sichern. Warum? Siehst Du in dem Logfile.

BFF

Im Hex Editor so

Oh, das ist ein Bug der nicht umgangen werden kann. Die ersten beiden zeichen sind das Byte Order Mark für UTF-16 LE (was man bei Microsoft als "Unicode" versteht). Das führt dazu, dass der nachfolgende Text vom Editor 2-Byte- (bei Surrogates 4-Byte-) weise gelesen wird, so wie das für UTF-16 auch richtig wäre. Der gesamte nachfolgende Text ist aber ANSI codiert. Das führt die /unilog Option ad absurdum. Anders gesagt, selbst wenn du das Byte Order Mark entfernst, hast du anschließend trotzdem nur ANSI.

Kopiert man die Windows 10 robocopy aus System32 und verwendet sie allein

Natürlich. Die meisten Kommandozeilentools im System32 Verzeichnis funktionieren nur in dieser Umgebung zuverlässig, da sie Abhängigkeiten zu anderen Dateien (DLL, MUI, ...) haben.

Nur... warum ist es sooo Langsam

Weil es die gesamten Ordnerstrukturen rekursiv durchlaufen muss und robocopy alles was gefunden wird anhand der übergebenen Optionen filtern muss.

loggt dabei auch noch Zugriff verweigert

Weil der Zugriff auf den Papierkorb verweigert wird. Dessen Inhalt ist virtualisiert.

Grüße
rubberman

hast du anschließend trotzdem nur ANSI

wie soll ich dann Pfade aufschreiben die Umlaute enthalten

Natürlich. Die meisten Kommandozeilentools im System32 Verzeichnis funktionieren nur in dieser Umgebung zuverlässig, da sie Abhängigkeiten zu anderen Dateien (DLL, MUI, ...) haben.

Ist es möglich herauszufinden welche?

Den Rest hab ich verstanden. Der dumme no line feed bug wird dadurch erzeugt das Robocopy irgendwas fehlt.
Ich würde Robocopy halt gerne mitnehmen, aber ob das möglich ist... die Umlaute müssen aber auf jeden Fall irgendwie drin sein, vielleicht könnte ich sie durch * ersetzten...? obwohl das vielleicht dumm wäre wenn Pfade oder Dateien sich nur durch 1 Umlaute unterscheiden obwohl das eher unwahrscheinlich ist

lg clragon

Umlaute sind doch kein Problem, oder? Hab's jetzt nicht getestet, aber ein
>nul chcp 1252
sollte es tun. Natürlich dasselbe, wenn du die Datei anschließend wieder per Batch parst
(Oder du lässt es für beide Male weg, was dann im Editor etwas merkwürdig aussieht, aber nicht für die Konsoleprogramme.)

Ich würde Robocopy halt gerne mitnehmen

Nein, nein, nein. Welches willst du denn mitnehmen? Die 32- oder die 64-Bit Version? Was ist wenn du in den WOW64 Modus rein läufst? Vergiss das besser gleich wieder

Grüße
rubberman

Ich kann ohne unilog gehen und die Pfade funktionieren obwohl sie im Editor schlecht aussehen? das wusste ich gar nicht....

Ich würd .. ehm... die 32bit version mitnehmen da die auch in 64 bit laufen würde...? hmm.. vielleicht auch nicht XD

lg clragon

Ich kann ohne unilog gehen und die Pfade funktionieren obwohl sie im Editor schlecht aussehen?

Sicher funktioniert Batch immer nur mit ASCII Zeichen. ANSI funktioniert, solange die Zeichen in der OEM Code Page (das ist die, die Konsoleanwendungen verwenden) vorhanden sind, oder du per CHCP auf eine Code Page umstellst die diese Zeichen unterstützt. Unicode hilft dir in Batch in der Regel gar nicht, da du für dessen Verarbeitung bspw. per TYPE wieder in die ANSI Code Page konvertieren musst.

Ich würd .. ehm... die 32bit version mitnehmen da die auch in 64 bit laufen würde...?

Und dann? Lieferst du die 32 Bit System-DLLs mit aus und packst sie in das Arbeitsverzeichnis, würden die anderen Tools unter Umständen auch darauf zugreifen und der ganze Kram geht in die Grütze. Kann auch sein, dass das völlig wurscht ist und Robocopy trotzdem auf die registrierten DLLs im System32/SysWOW64 Verzeichnis zugreifen. Wenn die nicht zur Robocopy Version passen, hat es sich auch erledigt.

Grüße
rubberman

Na gut. Dann nehme ich das so an. Danke wiedermal für die excellente Hilfe, bin schon ein ganzes Stück weiter!
Ich werd demfall das mit Robocopy mitnehmen lassen, und /unilog rauschmeissen, und an stattdessen /log verwenden.
Danke.

lg clragon

EDIT: habs herausgefunden. Jetzt weiss ich es. Kopiert man die Windows 10 robocopy aus System32 und verwendet sie allein anstatt der System exe, wird dieses gewurschtel erzeugt. nur; warum?

Auch das Unterverzeichnis de-DE (bzw. gewünschte/verwendete Sprache) ist anzulegen. Darin einzig und allein die Datei Robocopy.exe.mui.

Natürlich haben die Einwände von Rubberman ihre Berechtigung...

Ja, Rubberman hat auf jeden Fall recht.

Ich schlage mich in zwischen auch lieber mit Python rum, da gibt es viele Möglichkeiten und die meisten Probleme sind weil ich etwas falsch verwende oder es keine Bibliothek dafür gibt und nicht weil die Sprache an sich limitiert ist.

gelöst Frage Entwicklung Batch, Shell

Heiß diskutiert