Robocopy sieht identische Dateien als geändert an (/fft hilft nicht)

[pinch]

Hallo Synology-Community,

es handelt sich hier nicht um ein übliches Robocopy-Problem, sondern scheint etwas verzwickter. Ich habe mich schon Stunden mit meinem Problem beschäftigt, gegoogelt, rumprobiert... es hat alles nicht geholfen. Threads in anderen Foren schlafen ein, weil sich scheinbar niemand damit befassen will, oder niemand über "probier's mal mit /fft" hinaus weiter weiß. Vllt waren meine bisherigen Hilfeersuche auch zu ausführlich und lang. Ich mache es hier daher kurz:

Problem: Dateien, die auf einer lokalen externen Festplatte und einer DS413j vorhanden und identisch sind (mit Robocopy oder Windows Explorer kopiert), werden beim zweiten Durchgang mit Robocopy als geändert angesehen und erneut kopiert. Bei hunderten GB ist dies unerwünscht.
Systemdetails: Windows 8 Pro, NTFS, Blockgröße 4K -- per CIFS eingebundenes Netzlaufwerk --> DS413j, DSM 4.2, Ext4, Blockgröße 4K

Folgendes habe ich probiert:

• /fft
• /dst
• SMB Blockgröße von 1K auf 4K ändern

Wichtig: Dateien werden als geändert angesehen, nicht als älter/neuer. der /fft-Switch scheint hier also irrelevant.

Vorgehensweise, die zum Problem führt:

1. lokal in "D:\Beispiel" eine Textdatei erstellen (nicht umbenennen, bleibt also "Neue Textdatei.txt")
2. lokal in "D:\Beispiel" eine weitere Textdatei ertellen - diesmal umbenennen, z.B. "test.txt"
3. Disk Station per Netzlaufwerk einbinden - Z:\
4. Robocopy Befehl starten - robocopy "D:\Beispiel" "Z:\Beispiel" /fft
5. Robocopy erneut starten - robocopy "D:\Beispiel" "Z:\Beispiel" /fft

Im Log in der Kommandozeile sieht man nun, dass die umbenannte Datei als geändert angesehen wird, die nicht umbenannte Datei nicht. Dieses Verhalten verstehe ich nicht und es scheint der Grund für das Problem zu sein.

Robocopy Befehlsvarianten helfen hier nicht:

echo off

set source=D:\Example
set target=Z:\Example

robocopy "%source%" "%target%1"
robocopy "%source%" "%target%2" /fft
robocopy "%source%" "%target%3" /fft /dst
robocopy "%source%" "%target%4" /e /purge
robocopy "%source%" "%target%5" /e /purge /fft
robocopy "%source%" "%target%6" /e /purge /fft /dst
robocopy "%source%" "%target%7" /mir
robocopy "%source%" "%target%8" /mir /fft
robocopy "%source%" "%target%9" /mir /fft /dst
robocopy "%source%" "%target%10" /mir /dcopy:T
robocopy "%source%" "%target%11" /mir /dcopy:T /fft
robocopy "%source%" "%target%12" /mir /dcopy:T /fft /dst

pause

Überall das gleiche Problem.

Ich wäre überglücklich über eine Lösung des Problems! Bei den meisten Leuten klappt es mit Robocopy und /fft ohne Probleme, es muss also gehen. Andere Software und Workarounds würde ich also gerne erstmal außen vor lassen. Aber wenn es nicht anders geht, bin ich auch hier Vorschlägen gegenüber offen.

Vielen Dank im Voraus!

 

[pinch]

Zweiter Post reserviert für die Sammlung von Antworten und Workarounds.

Einen Workaround habe ich gefunden:

Ein iSCSI LUN und Target erstellen, in Windows einbinden, in der Datenträgerverwaltung mit NTFS formatieren.
Mit Robocopy gibt es dann keine Probleme mehr.
Signifikanter Nachteil: Es ist kein gemeinsamer Ordner, er lässt sich nicht mit der File Station und vor allem nicht mit SFTP oder WebDAV, entsprechend nicht über das Internet erreichen. Auch lokal kommt man mit z.B. einem Android Smartphone nicht mehr an die Daten ran (was vorher mit z.B. ES File Explorer ging)!
(Zugriff von entferntem Windows PC mit Port Forwarding auf 3260 sicher möglich, aber Übertragung ist unverschlüsselt -> No Go. iSCSI Volume per TrueCrypt verschlüsseln wäre wiederum ein Workaround und würde neue Nachteile mit sich bringen. VPN ebenso.)

Dies ist also keine gute Lösung des Problems. Bei anderen funktioniert es ja normal mit Robocopy und gemeinsamen Ordnern - es muss also gehen.
Ich bitte also weiterhin um Hilfe

 

[Benares]

Ich hatte kürzlich genau das gleiche Problem, da hat /FFT wunderbar geholfen. Momentan arbeite ich mit

robocopy <Quelle> <Ziel> /MIR /XO /FFT

wobei <Ziel> direkt der UNC-Pfad ist (\\DS212\<Share>\...)

Gruß Benares

 

[pinch]

Danke für deine Antwort. Mit dem direkten Netzwerkpfad statt Netzlaufwerk war ne gute Idee, das hatte ich noch gar nicht probiert. Geholfen hat es aber leider nicht.

 

[Theslowman]

Leider in Englisch, aber hier lohnt es sich zu lesen.


Microsoft Technet W8 Robocopy Problem

Gruß TSM

 

[pinch]

Danke für den Link! Ich hab zwar viel gesucht, aber das nicht gefunden.
Leider werden dort auch eher Workarounds beschrieben. Auf jeden Fall scheint es sich um ein Problem zu handeln, was nicht meiner Benutzung, sondern dem Tooling geschuldet ist.
Die dort beschriebenen Workarounds habe ich jetzt nicht ausprobiert. Ich nutze nun erstmal die iSCSI-Lösung und hoffe auf ein Robocopy-Update mit Windows 8.1.