Inoffizielles deutsches Xbase-Forum

ROBOCOPY und NAS ...
Der Befehl ROBOCOPY (von M$) kopiert Dateien falls diese im Zeitstempel neuer sind (vermutlich auch bei Unterschieden in der Größe) .
Wenn eine Datei blockiert ist, wartet er bis sie frei wird - der Befehl ist recht alt, war aber gut versteckt für Serveradmins (SDK glaube ich).

Ich nutze ihn um einen Verzeichnisbaum auf 2 Rechnern identisch zu halten (auch Löschungen werden nachvollzogen.)
Nun bekam ich ein NAS von Tera ... hier behauptet ROBOCOPY bei fast jeder Datei dass diese blockiert ist (Syncronisationsangaben blockiert oder so),
wartet 30 Sekunden und kopiert dann einige bevor die Meldung wiederkommt. Zeitlich nicht zu gebrauchen.
Beim Synologie NAS macht ROBOCOPY das nicht, aber es erkennt auch nicht dass zwei Dateien gleich sind und kopiert immer alles (mach ich ab und zu über Nacht )

Alle Geräte syncronisieren die Uhren regelmäßig und auch sonst ist nicht zu erkennen woran es liegen könnte ...

Ich benutze ROBOCOPY seit Windows Vista. Es ist seit dem im Betriebssystem enthalten. Es werden folgende Parameter benutzt:

ROBOCOPY "C:\Quelle" "Z:\Ziel" /MIR /XO /NDL /NJH /NJS /TEE /XJ /R:0 /W:0 /LOG+:LogDatei.txt

Wichtig ist der Parameter XO, da sonst neuere Dateien im Ziel von älteren aus der Quelle überschrieben werden. Des weiteren ist der Parameter XJ wichtig. Er verhindert das ROBOCOPY bei manchen PC´s in eine Endlosschleife läuft. Das heißt im Ziel wird endlos das gleiche Verzeichnis
als Unterverzeichnis gespeichert.

Gruß Johann

brandelh hat geschrieben:Beim Synologie NAS macht ROBOCOPY das nicht, aber es erkennt auch nicht dass zwei Dateien gleich sind und kopiert immer alles (mach ich ab und zu über Nacht )

Alle Geräte syncronisieren die Uhren regelmäßig und auch sonst ist nicht zu erkennen woran es liegen könnte ...

Hallo Hubert,

verwende mal zusätzlich den Parameter /FFT. Das von Dir beschriebene Problem entsteht dann, wenn die verwendeten Dateisysteme (quelle und ziel) den Zeitstempel mit unterschiedlicher Granularität speichern (z. B. FAT/FAT32/NTFS), also unterschiedlich "genau" sind. Der Parameter /FFT vergleicht anhand der (recht ungenauen Granularität von FAT: 2 sec) und eliminiert so in aller Regel das geschilderte Problem.

Der Hinweis auf /XO war schon gut - wer will schon neuere mit älteren überschreiben ...

Markus Walter hat geschrieben:Der Parameter /FFT vergleicht anhand der (recht ungenauen Granularität von FAT: 2 sec) und eliminiert so in aller Regel das geschilderte Problem.

aber seit /FFT funktioniert es SUPER danke an euch.

Ich habe für das ROBOCOPY Thema einen eigenen Thread abgetrennt.

brandelh hat geschrieben:Der Hinweis auf /XO war schon gut - wer will schon neuere mit älteren überschreiben ...

Da würde ich zumindest mal drüber nachdenken (in Verbindung mir /MIR). /MIR wird explizit zum Spiegeln von Daten verwendet (es werden auch nicht mehr existierende Dateien im Ziel gelöscht). Da gehört (zumindest für mich) /XO nicht hin. Bei /MIR will man in der Regel eine 1:1 Spiegelung haben.

Mal folgendes Beispiel aus der Praxis: Wenn man für seine Quellen eine Versionsverwaltung (wie z. B. Subversion) verwendet, zusätzlich aber mit Robocopy irgendwohin spiegelt. Wenn Du nun durch die Versionsverwaltung eine prg "zurücksetzt", sprich eine ältere Datei wiederherstellst, würde diese beim nächsten Robocopy-Lauf nicht in die Spiegelung übertragen...

brandelh hat geschrieben: aber seit /FFT funktioniert es SUPER danke an euch.

Gerne.

Ja, /XO muss man sich gut überlegen, eine Versionsverwaltung habe ich nicht, und eigentlich arbeite in nur in dem Quellverzeichnis.