12
Robocopy - viele failed dirs, aber nichts im Log
Hallo zusammen,
ich habe ein interesantes Phänomen mit robocopy. Aus Gründen muss ich ein komplettes Laufwerk mehr oder minder "live" spiegeln.
Soweit sieht das auch alles gut aus, gäbe es da nicht am Ende die Robocopy-Zusammenfassung, die mir sagt, es wären 275 Verzeichnisse fehlgeschlagen.
Sieht dann so aus:
Robocopy-Parameter: /TEE /S /E /DCOPY:DA /COPY:DATS /PURGE /MIR /B /NP /MT:8 /R:1 /W:1
Ich hatte da auch ein paar zu lange Dateinamen dabei, etc. - aber das zeigt er mir im Log entsprechend an und damit kann ich das beheben,
Allerdings erwarte ich im Log eigentlich auch 275 Einträge zu den fehlgeschlagenen Verzeichnissen. Da ist aber nichts zu sehen. Wenn ich mit /NFL /NDL nur Fehler ausgeben lasse, ist das Log nahezu leer.
Hatte das Phänomen schon einmal jemand und hat dazu evtl. eine erklärung?
ich habe ein interesantes Phänomen mit robocopy. Aus Gründen muss ich ein komplettes Laufwerk mehr oder minder "live" spiegeln.
Soweit sieht das auch alles gut aus, gäbe es da nicht am Ende die Robocopy-Zusammenfassung, die mir sagt, es wären 275 Verzeichnisse fehlgeschlagen.
Sieht dann so aus:
------------------------------------------------------------------------------
Total Copied Skipped Mismatch FAILED Extras
Dirs : 1034698 1034698 0 0 275 2
Files : 6941468 112 6941457 0 14 1
Bytes : 5.635 t 25.89 m 5.635 t 0 14.53 m 8.500 g
Times : 0:27:56 0:00:01 0:00:00 0:27:52
Ended : Wednesday, December 20, 2023 2:33:13 AMRobocopy-Parameter: /TEE /S /E /DCOPY:DA /COPY:DATS /PURGE /MIR /B /NP /MT:8 /R:1 /W:1
Ich hatte da auch ein paar zu lange Dateinamen dabei, etc. - aber das zeigt er mir im Log entsprechend an und damit kann ich das beheben,
Allerdings erwarte ich im Log eigentlich auch 275 Einträge zu den fehlgeschlagenen Verzeichnissen. Da ist aber nichts zu sehen. Wenn ich mit /NFL /NDL nur Fehler ausgeben lasse, ist das Log nahezu leer.
Hatte das Phänomen schon einmal jemand und hat dazu evtl. eine erklärung?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 3570010414
Url: https://administrator.de/contentid/3570010414
Printed on: May 3, 2024 at 08:05 o'clock
12 Comments
Latest comment
Moin,
setze den Parameter dann wird mehr protokolliert. Leite das LOG in eine Datei um. Damit Du in Ruhe analysieren kannst.
Gruss Penny.
setze den Parameter
/V,Gruss Penny.
Zitat von @Penny.Cilin:
Moin,
setze den Parameter dann wird mehr protokolliert. Leite das LOG in eine Datei um. Damit Du in Ruhe analysieren kannst.
Gruss Penny.
Moin,
setze den Parameter
/V,Gruss Penny.
/LOG ist sowieso an, dahin protokolliere ich immer.
Mit /V wird man aber auch nicht schlauer. Die Fehler sind auch da nicht drin.
Moin @HellstormDe
zu lange Datei/Verzeichnisnamen sind in robocopy eigentlich eher nicht das Problem. Es täuscht etwas, aber unter windows werden lange Datei und Verzeichnisnamen durchaus unterstützt, nur der Datei-Explorer ausgerechnet kommt damit nach wie vor nicht klar.
Es wir so vermute ich ein Rechte-Problem oder unzulässige Zeichen in den Verzeichnisnamen sein.
Kreuzberger
zu lange Datei/Verzeichnisnamen sind in robocopy eigentlich eher nicht das Problem. Es täuscht etwas, aber unter windows werden lange Datei und Verzeichnisnamen durchaus unterstützt, nur der Datei-Explorer ausgerechnet kommt damit nach wie vor nicht klar.
Es wir so vermute ich ein Rechte-Problem oder unzulässige Zeichen in den Verzeichnisnamen sein.
Kreuzberger
Damit kommt nicht nur der Explorer nicht klar. Auch über cmd kann ich die Verzeichnisse weder öffnen, noch umbenennen, etc... - da half tatsächlich nur das Kürzen der (teils übergeordneten) Verzeichnisnamen.
Aber Access Rights kann ich auch so gut wie ausschließen. Sollte ich ein Verzeichnis wegen ACLs, resp. NTFS Permissions nicht aufrufen können, erhalte ich eigentlich zumindest den Error 00005 - Access Denied.
Solche Meldungen hatte ich ja zu beginn an wenigen Stellen - aber da habe ich mir mit takeown schon Zugriff verschafft.
Was da aktuell vorgeht, ist echt ein Mysterium...
Aber Access Rights kann ich auch so gut wie ausschließen. Sollte ich ein Verzeichnis wegen ACLs, resp. NTFS Permissions nicht aufrufen können, erhalte ich eigentlich zumindest den Error 00005 - Access Denied.
Solche Meldungen hatte ich ja zu beginn an wenigen Stellen - aber da habe ich mir mit takeown schon Zugriff verschafft.
Was da aktuell vorgeht, ist echt ein Mysterium...
Stehen im Logfile nicht die Exitcodes von Robocopy?
Die Tiefen de Internets (zweiter Treffer bei Google-Suche nach robocopy failed directories) meint
Außerdem noch ein Link zu den Exitcodes:
https://learn.microsoft.com/en-us/archive/blogs/deploymentguys/robocopy- ...
Die Tiefen de Internets (zweiter Treffer bei Google-Suche nach robocopy failed directories) meint
robocopy b:\destinationdoesnotexist C:\documents /MIR
if ($lastexitcode -eq 0)
{
write-host "Robocopy succeeded"
}
else
{
write-host "Robocopy failed with exit code:" $lastexitcode
}Außerdem noch ein Link zu den Exitcodes:
https://learn.microsoft.com/en-us/archive/blogs/deploymentguys/robocopy- ...
Die Exit codes helfen da leider nicht weiter. Die sind mir soweit auch bekannt. Alles >=8 bedeutet Fehler.
Die stehen aber nicht im Log, da es ja ein exit code ist. Im Log stehen halt nur die Fehlercodes zu einzelnen Dateien/Verzeichnissen, die auf Fehler gelaufen sind.
Meine genannten 275 Verzeichnisse sind da aber nicht aufgelistet. Würde ich mich nur auf das Log verlassen, könnte man denken, Robocopy ist sauber durchgelaufen. - Aber wie gesagt, das ist es ja nicht.
Die stehen aber nicht im Log, da es ja ein exit code ist. Im Log stehen halt nur die Fehlercodes zu einzelnen Dateien/Verzeichnissen, die auf Fehler gelaufen sind.
Meine genannten 275 Verzeichnisse sind da aber nicht aufgelistet. Würde ich mich nur auf das Log verlassen, könnte man denken, Robocopy ist sauber durchgelaufen. - Aber wie gesagt, das ist es ja nicht.
Sind das eventuell Verzeichnisse, welche aufgrund von Attributen nicht kopiert werden können? Zum Beispiel "System Volume Information".
Vielleicht auch Mal mit dem Parametern experimentieren
Weil manche Dateien / Verzeichnisse lasen sich aufgrund der Attribute nur mit weiteren Parameter kopieren.
Muss man halt experimentieren.
Gruss Penny.
Vielleicht auch Mal mit dem Parametern
/xd /b /zbWeil manche Dateien / Verzeichnisse lasen sich aufgrund der Attribute nur mit weiteren Parameter kopieren.
Muss man halt experimentieren.
Gruss Penny.
Die Switches werde ich auch noch mal testen. Im Normalfall arbeite ich mit /b. Vielleicht bringt ja /zb was anderes.
System Volume Information ist aber IMHO nicht das Problem. Das wiederum zeigt mir Robocopy nämlich mit Fehler an.
System Volume Information ist aber IMHO nicht das Problem. Das wiederum zeigt mir Robocopy nämlich mit Fehler an.
@HellstormDe
hier mal die Parameter, welche ich für Robocopy nutze:
Die Umgebungsvariablen %EXCLDIR% und %EXCLFIL% werden vor Aufruf von Robocopy gesetzt.
Die Parameterkannst Du weglassen, weil diese sind Standard. Brauchst du somit nicht angeben.
Gruss Penny.
hier mal die Parameter, welche ich für Robocopy nutze:
/V /X /S /E /Copy:DAT /DST /TS /FP /NP /XD %EXCLDIR% /XF %EXCLFIL% /XP /R:10 /W:0 /TeeDie Umgebungsvariablen %EXCLDIR% und %EXCLFIL% werden vor Aufruf von Robocopy gesetzt.
Die Parameter
/DCOPY:DA /MT:8Gruss Penny.
Die Verzeichnisse habe ich nun gefunden, die betroffen sind.
Warum robocopy dazu nichts im Log anzeigt, ist mir aber weiterhin unbekannt.
Zur Auflösung: Es handelt sich offensichtlich um Dateisystemfehler.
Ich habe mir ein kleines Powershell-Script erstellt, das rekursiv robocopy auf Unterverzeichnisse erneut ausführt, sobald der exitcode größer gleich 8 ist.
Damit konnte ich mich sukzessive in den Verzeichnissen nach unten hangeln. Über Powershell: Get-ChildItem war es dann möglich, den genauen Übeltäter zu finden, denn wenn Get-ChildItem auf ein Verzeichnis stößt, das nicht lesbar ist, erzeugt es eine Exception, die ich dann einfach abgefangen habe.
Und für alle fehlschlagenen Verzeichnisse hatte ich dann folgende Exception: "The file or directory is corrupted and unreadable."
Aber wie gesagt: Warum das robocopy nicht im log anzeigt, ist mir schleierhaft. Normale Fehler, z.B. wegen unzureichender NTFS-Permissions werden ja erwartungsgemäß angezeigt. Aber hier werden die Fehler nur im robocopy summary gezählt, aber nicht protokolliert.
Warum robocopy dazu nichts im Log anzeigt, ist mir aber weiterhin unbekannt.
Zur Auflösung: Es handelt sich offensichtlich um Dateisystemfehler.
Ich habe mir ein kleines Powershell-Script erstellt, das rekursiv robocopy auf Unterverzeichnisse erneut ausführt, sobald der exitcode größer gleich 8 ist.
Damit konnte ich mich sukzessive in den Verzeichnissen nach unten hangeln. Über Powershell: Get-ChildItem war es dann möglich, den genauen Übeltäter zu finden, denn wenn Get-ChildItem auf ein Verzeichnis stößt, das nicht lesbar ist, erzeugt es eine Exception, die ich dann einfach abgefangen habe.
Und für alle fehlschlagenen Verzeichnisse hatte ich dann folgende Exception: "The file or directory is corrupted and unreadable."
Aber wie gesagt: Warum das robocopy nicht im log anzeigt, ist mir schleierhaft. Normale Fehler, z.B. wegen unzureichender NTFS-Permissions werden ja erwartungsgemäß angezeigt. Aber hier werden die Fehler nur im robocopy summary gezählt, aber nicht protokolliert.
Sorry für die späte Antwort. Hatte aber nicht eher Zeit gefunden.
Ja, das Script kann ich euch geben. Allerdings unter Ausschluss jeglicher Gewährleistung.
Es ist halt recht schnell zusammengewürfelt, da es nur mir alleine diente. Ohne großartige Fehlerüberprüfung oder "Bereinigung" von Parametern.
Prinzipiell wird als Startschuss einfach nur die Funktion "dive" aufgerufen, mit den Parametern bspw. -source "D:" -target "Y:" -dir "" -logfile "C:\log.txt"
-source und -target sind dabei die Laufwerke, die verwendet werden und wenn man statt des ganzen Laufwerkes nur spezielle Verzeichnisse kopieren will, dann gibt man bei -dir halt den Verzeichnisnahmen OHNE führende und nachfolgende Backslashes an, bspw. -dir "data\foo\bar".
Ist eben dafür gedacht, eine Struktur 1:1 zu übernehmen. Andernfalls müsste man halt das Script anpassen oder einen kleinen Parser einbauen. Wäre für meinen Zweck aber zeitlich den Aufwand nicht wert gewesen.
Es wird in eine Datei gelogged, sobald ein Fehler auftritt. Zusätzlich wird in die Konsole geschrieben. Rot für Dateisystemfehler, gelb für alle anderen Fehler.
Vom Quellverzeichnis wird die Liste der Verzeichnisse abgefragt. Die einzelnen Verzeichnisse werden dann an robocopy übergeben.
Hierbei ist zu beachten, dass Powershell dann via Get-ChildItem den Fehler auslöst, den robocopy so schön im Log verschweigt.
Da Get-ChildItem mit -recurse bei großen Verzeichnissen eine Memory Exception auslösen kann und extrem langsam ist, wird der Umweg über robocopy selbst gegangen.
Prinzipiell wird dabei der Rückgabewert von Robocopy ausgewertet. Ist der größer als 7, haben wir es mit einem Fehler zu tun und das entsprechende Verzeichnis wird dann iterativ wieder abgefragt und durchlaufen.
Das erhöht prinzipiell die Anzahl der Lesevorgänge, weil eben fehlerbehaftete Verzeichnisse ggfls. bis ganz nach unten durchlaufen werden müssen - aber es ist ja auch nur für sehr spezielle Probleme gedacht.
Ja, das Script kann ich euch geben. Allerdings unter Ausschluss jeglicher Gewährleistung.
Es ist halt recht schnell zusammengewürfelt, da es nur mir alleine diente. Ohne großartige Fehlerüberprüfung oder "Bereinigung" von Parametern.
Prinzipiell wird als Startschuss einfach nur die Funktion "dive" aufgerufen, mit den Parametern bspw. -source "D:" -target "Y:" -dir "" -logfile "C:\log.txt"
-source und -target sind dabei die Laufwerke, die verwendet werden und wenn man statt des ganzen Laufwerkes nur spezielle Verzeichnisse kopieren will, dann gibt man bei -dir halt den Verzeichnisnahmen OHNE führende und nachfolgende Backslashes an, bspw. -dir "data\foo\bar".
Ist eben dafür gedacht, eine Struktur 1:1 zu übernehmen. Andernfalls müsste man halt das Script anpassen oder einen kleinen Parser einbauen. Wäre für meinen Zweck aber zeitlich den Aufwand nicht wert gewesen.
Es wird in eine Datei gelogged, sobald ein Fehler auftritt. Zusätzlich wird in die Konsole geschrieben. Rot für Dateisystemfehler, gelb für alle anderen Fehler.
Vom Quellverzeichnis wird die Liste der Verzeichnisse abgefragt. Die einzelnen Verzeichnisse werden dann an robocopy übergeben.
Hierbei ist zu beachten, dass Powershell dann via Get-ChildItem den Fehler auslöst, den robocopy so schön im Log verschweigt.
Da Get-ChildItem mit -recurse bei großen Verzeichnissen eine Memory Exception auslösen kann und extrem langsam ist, wird der Umweg über robocopy selbst gegangen.
Prinzipiell wird dabei der Rückgabewert von Robocopy ausgewertet. Ist der größer als 7, haben wir es mit einem Fehler zu tun und das entsprechende Verzeichnis wird dann iterativ wieder abgefragt und durchlaufen.
Das erhöht prinzipiell die Anzahl der Lesevorgänge, weil eben fehlerbehaftete Verzeichnisse ggfls. bis ganz nach unten durchlaufen werden müssen - aber es ist ja auch nur für sehr spezielle Probleme gedacht.
function dive {
param (
[string]$source,
[string]$target,
[string]$dir,
[string]$logfile
)
$root = $source+"\"+$dir
Get-ChildItem -Directory $root -ErrorAction Continue 2>&1 | % {
if($_ -is [System.Management.Automation.ErrorRecord]) {
$e = $_.Exception.Message -replace "`n",""
if($e -match "The file or directory is corrupted and unreadable.") {
Write-Host -Fore Yellow "[$($e)] $($_.TargetObject)"
} else {
Write-Host -Fore Magenta "[$($e)] $($_.TargetObject)"
}
$_.TargetObject | Out-File -Append -FilePath $logfile
} else {
$srcroot = $_.FullName
$dstroot = $srcroot -replace "^$($source)",$target
$return = & robocopy $srcroot $dstroot "/ZB" "/MIR" "/SEC" "/MT:8" "/R:0" "/W:0" "/NP" "/XJD" "/XJF" "/NJH" "/NFL" "/NDL"
if($LASTEXITCODE -gt 7) {
Write-Host -Fore Red "Failed: $($srcroot) -> $($dstroot)"
$fail = $srcroot -replace "^$($source)\\",""
dive -dir $fail -source $source -target $target -logfile $logfile
} else {
#if you need commands for succeeded runs, then they go here
}
}
}
}
dive -source "D:" -target "Y:" -dir "" -logfile 'C:\errors0.txt' 
