DFS-R Konflikterkennung

[Abrabravo 10]

Hallo zusammen,

 

wie im Titel zu erkennen habe ich eine Frage zur Funktionsweise der Konflikterkennung in DFS-R replizierten Ordnern.

 

Folgende Situation:

Nehmen wir mal an, es gibt die Datei "wurstsuppe.txt" in einem per DFS-R replizierten Ordner. Dieser DFS-R Ordner ist in einem domainbasierten DFS-N Stamm freigegeben und veröffentlicht. Alles genau so, wie es im Tutorial auf serverhowto.de beschrieben ist. Die Replikation ist ununterbrochen mit voller Bandbreite. Es funktioniert alles wunderbar.

 

10:00 Uhr: User1 an Standort A öffnet Datei "wurstsuppe.txt"

10:01 Uhr: User2 an Standort B öffnet ebenfalls die Datei "wurstsuppe.txt" aus dem gleichen per DFS-R replizierten Ordner welcher per DFS-N freigegeben ist, jedoch liegt die Datei bei ihm ja physisch auf einem anderen Server (da anderer Standort).

 

10:05 Uhr: User1 an Standort A speichert die Datei "wurstsuppe.txt"

10:08 Uhr: User2 an Standort B speichert die Datei "wurstsuppe.txt"

 

Nach meinem Verständnis müsste doch nun die Datei von User1 in den Ordner "ConflictAndDeleted" verschoben werden und es sollte ein Ereignis im Windows EventLog erscheinen. Auf dem DFS sollte dann die Datei "gewinnen", welche als letztes gespeichert wurde.

 

Nun die Frage: Ist das wirklich so?

 

Ein Kollege und ich konnten das so definitiv bei Word-Dateien beobachten - alles fein.

Durch Zufall ist jetzt in einer Testumgebung jedoch der Effekt aufgetaucht, dass die Datei von User1 nicht in den "ConflictAndDeleted" Ordner verschoben wird und es auch keinen Eventlog Eintrag gibt. Es handelte sich hierbei um .TXT-Files, welche mit dem Editor oder Wordpad geöffnet wurden. Das wäre ja fatal! In der Umgebung ist am Ende nur die Datei von User2 zu finden.

 

Kann es sein, dass MS Office Dateien anders behandelt werden als andere Files? (PDF Dateien, CAD Files, etc.)

 

 

Ich danke schonmal vorab für Eure Bemühungen und hoffe auf eine aufschlussreiche Diskussion! ;-)

 

 

MfG,

Norman.

[olc 18]

Hi Norman,

 

wenn es einen Konflikt gibt dann wird dieser auch ein Konfliktevent nach sich ziehen. Ohne genau das Szenario zu kennen, welches Du da beschrieben hast, läßt sich schwer mehr dazu sagen. ;)

 

Vielleicht habt Ihr lediglich auf dem falschen Server geschaut.

 

Ansonsten gilt:

- Bei bestehenden Dateien greift das Prinzip "last writer wins".

- Wenn eine neue Datei erstellt wird, gewinnt bei einem Konflikt meiner Erinnerung nach die zuerst erstellte Datei.

- Ähnlich läuft es ab bei einem Ordner, der jedoch ggf. gemerged wird - je nach Szenario.

 

Office Dateien können sich insofern von Textdateien unterscheiden, als daß z.B. Excel oder Access Dateien im geöffneten Zustand nicht repliziert werden können (file locking). Ansonsten ist es aber im Prinzip das selbe wie bei Textdateien.

 

Viele Grüße

olc

[Abrabravo 10]

Hallöchen OLC,

 

und danke für die Antwort!

 

Ja, das habe ich soweit du das beschrieben hast auch alles in Erinnerung.

Jedoch wird im oben beschrieben Fall auf keinem der teilnehmenden Server ein Konflikt im Eventlog angezeigt und die Datei wird eben auch nicht verschoben. Wir haben das jetzt in 2 verschiedenen Umgebungen so nachstellen können. Aufgefallen ist dieses Verhalten in einer Testumgebung und nachgestellt wurde es in unserem Produktivsystem.

 

Die Option, dass der Ordner "ConflictAndDeleted" verwendet wird ist aktiviert.

 

Hat jemand noch eine Idee?

 

MfG,

Norman.

[olc 18]

Hi,

 

ein Punkt ist wichtig: Editoren wie Notepad stellen keine "file locks" auf Textdateien. Damit wird bei geöffneten Schedule die Änderung an Datei1 auf Server1 direkt repliziert, auch wenn Datei1 auf Server2 gerade geöffnet ist.

 

Speichert nun der Benutzer auf Server2 die Datei1, ist es ein komplett neuer Schreibvorgang / eine neue Änderung, egal was in der Datei1 von Server1 vorher ankam.

 

Somit würde auch kein Konflikt entstehen - der Konflikt käme lediglich zu stande, wenn der Schedule geschlossen gewesen wäre und auf beiden Seiten Änderungen durchgeführt worden wären.

 

Viele Grüße

olc

[Abrabravo 10]

Hoi,

 

ja genau so scheint es sich zu erklären.

Das ist natürlich wenn man es genauer betrachtet eine ziemlich heikle Situation! Im Umkehrschluss für mich bedeutet dies, dass ich genau prüfen muss, welche Dateitypen dieses File Lock "Attribut" unterstützen.

 

Bei einem über DFS-N freigegebenen replizierten Ordner über mehrere Standorte hinweg kann man ja dadurch nicht sicherstellen, dass 2 Leute an der gleichen Datei arbeiten. Heieiei!

 

Okay, das hat uns schon sehr geholfen!

 

Vielen Dank!!

 

MfG,

Norman.

[olc 18]

Hi Norman,

 

genau das ist einer der Kernpunkte bei der Planung von DFSR in Verbindung mit DFSN - es ist schlichtweg nicht dafür vorgesehen (DFSR)...

 

Soll heißen: Daten einsammeln (z.B. für Backups) oder die Datenverteilung (z.B. WDS Freigaben) sind vom Design her sinnvoll für DFSR. Die gleichzeitige Arbeit an gleichen Dokumenten aber an unterschiedlichen Orten sollte im Grunde niemals stattfinden.

 

Und auch das File Locking schützt Dich nicht vor Konflikten - wenn also eine Excel Datei während der Bearbeitung "gesperrt" ist, dann gilt das nur für den einen Server(!). Auf dem anderen Server kann gleichzeitig ebenfalls in der Exdel Datei gearbeitet werden.

Das File Locking wird nicht "repliziert", es gilt ausschließlich lokal...

Wenn dann die Dateien geschlossen werden, kommt es direkt zum Konflikt oder zum Überschreiben der Dateien.

 

BTW: Das Notepad Problem hättest Du übrigens auch auf einem einzigen Share, nicht nur bei dieser Kombination. ;)

 

Viele Grüße

olc