nicht angemeldet
Mehrbenutzerzugriff
TS
Rolf bHallo,
wie funktioniert ein Mehrbenutzerzugriff-System bei Dateien? Es gibt ein verteiltes System, über das verschieden Dateien auf einem Server abgelegt werden. Danach können die Benutzer von überall darauf zugreifen und diese Bearbeiten bzw. ändern. Wie wird dies nun gehandhabt?
Gruß
-
Tach!
Es gibt ein verteiltes System, über das verschieden Dateien auf einem Server abgelegt werden. Danach können die Benutzer von überall darauf zugreifen und diese Bearbeiten bzw. ändern. Wie wird dies nun gehandhabt?
Ein Prinzip ist ein Netzwerklaufwerk. Die Dateien liegen physisch auf einer zentralen Ressource und die Nutzer können sie anfordern, woraufhin sie zum Gerät des Benutzers übertragen werden. Änderungen werden anschließend wieder zurückgeschickt.
Ein weiteres verwendet dezentrale Kopien, mit oder ohne zentralem Master. Die Clients ziehen zunächst eine Kopie des Datenbestands und überwachen anschließend Änderungen, um dann die geänderten Dateien zu synchronisieren.
dedlfix.
-
Hi,
vielen Dank. Wie wird die Anforderung der Daten von Benutzern gehandelt? Wird das Ganze gestrimt? Wie organisiert man da den gleichzeitigen Zugriff? Das lesen sollte eigentlich kein Problem darstellen. Wie ist da beim Zurückschreiben der Daten/Dateien. Angenommen fordern 5 User das gleiche Bild-Datei und speichern es zugleich auch zurück.
Wie meinst du mit "ohne zentralen Master"? Wie kann das gehen?
Gruß
-
Tach!
Wie wird die Anforderung der Daten von Benutzern gehandelt? Wird das Ganze gestrimt?
Meinst du gestreamt? Streamen heißt, während der Übertragung bereits verwenden, wie zum Beispiel bei Videos. Das geht mit den meisnten Dateien normaler Programme nicht. Die gehen üblicherweise davon aus, dass die Dateien lokal vorhanden sind und sie vollen Zugriff haben.
Wie organisiert man da den gleichzeitigen Zugriff? Das lesen sollte eigentlich kein Problem darstellen. Wie ist da beim Zurückschreiben der Daten/Dateien. Angenommen fordern 5 User das gleiche Bild-Datei und speichern es zugleich auch zurück.
Kommt darauf an, wie die Clients implementiert sind. Ob sie solche Konflikte erkennen und Hinweise geben, oder ob einfach der letzte Schreibzugriff gewinnt.
Wie meinst du mit "ohne zentralen Master"? Wie kann das gehen?
Peer to peer. Man muss sich untereinander organisieren. Ist vielleicht keine so gute Idee, wenn es um ständige Verfügbarkeit geht, und die Möglichkeit besteht, dass Client sich aus dem Netz verabschieden können, und die Daten noch nicht auf noch im Netz befindlichen Clients synchronisiert wurden.
dedlfix.
-
-
-
Hallo und guten Abend,
wie funktioniert ein Mehrbenutzerzugriff-System bei Dateien?
Das sollte immer die Benutzer-API des Filesystems regeln.
Es gibt Hostsysteme, die per (Fern-)Konsole von mehreren Benutzern verwendet werden können. Die benötigen einen Port / Slot pro Fernkonsole.
Es gibt verteilte Netzwerkbetriebssysteme, die die Bearbeitung im Arbeitsspeicher des entfernten Clients vornehmen. Der Fileserver muss dazu eine netzwerhfähige API haben und der Client einen geeigneten Requester (Netzwerk-Shellextension).
Lies Dir mal den Artikel von Christian Seiler durch zum Thema Filelocking. Musst Du bitte mal selber im Wiki suchen. Vom Tablet ist verlinken immer recht mühselig.
Grüße
TS -
Welches Verfahren du brauchst, hängt von einigen Aspekten ab. Welcher Art ist dein "verteiltes System", wie lange dauert ein Bearbeitungszyklus, spielt das Edit-Programm mit, welche Security-Maßstäbe legst Du an, usw. Ich zähle mal ein paar Möglichkeiten auf.
-
Das Edit-Programm öffnet die Datei zur Bearbeitung mit einem Fileshare-Modus, der anderen nur das Lesen erlaubt (wie das konkret geht hängt vom Betriebssystem ab). Es hält die Datei während der Bearbeitung offen. Am Ende überschreibt es den Inhalt (oder Teile davon) und schließt die Datei. Ab jetzt können andere wieder bearbeiten. Vorteil: Ganz einfach zu lösen, und einen Lock des Betriebssystems kann man auch nicht umgehen. Nachteil: Wenn das Betriebssystem keine Funktion hat, die Auskunft über den Sperrbesitzer gibt, weiß man nicht, wer die Datei gerade sperrt. Nachteil 2: Man kann auf diese Weise eine Sperre nicht über längere Zeit halten. Beendet man das Edit-Programm, ist die Sperre wieder weg.
-
Variante von 1: Das Edit-Programm erzeugt am gleichen Ort, wo z.B. foo.txt steht, eine Datei _editlock_foo.txt (oder irgendwas in der Art) und schreibt dort hinein, wer die Datei gerade am Wickel hat. Diese Datei hält es während der Bearbeitung mit Schreibsperre offen. Vorteil: Man hat Metainformationen zum Bearbeitungsvorgang. Nachteil: Wer die Sperrdatei ignoriert, kann konkurrierend editieren.
-
1. und 2. kann man kombinieren, wenn das Format der bearbeiteten Dokumentdatei das hergibt.
-
Erweiterung von 2: Die Sperrdatei wird nicht gelockt, sondern die Existenz einer Sperrdatei wird vom Edit-Programm als Sperre anerkannt. Erst, wenn der Bearbeiter die Sperre explizit freigibt, akzeptiert es Bearbeitung durch andere Personen. Das erlaubt längere Bearbeitungszyklen, funktioniert aber nur wenn die Sperrdatei strikt respektiert wird. Auch hier kann man die Funktion der Sperrdatei in die Dokumentdatei integrieren, wenn das Dateiformat mitspielt.
-
Diese Verfahren kann man noch mit Schutzattributen im Filesystem des Betriebsystems garnieren, aber es ist genau das: Garnitur. Weil der User das Recht haben muss, diese Schutzattribute zu ändern, sonst könnte er nicht bearbeiten. Es hilft nur gegen versehentliche Aktionen.
Wenn dein Edit-Programm nicht darauf ausgelegt ist, Sperren irgendwelcher Art selbst zu managen, brauchst Du eine Serverkomponente. Dafür legt man die Dateien so ab, dass die Anwender sie nur lesen können (Fileshare mit Readonly-Recht oder eine Webseite mit Downloadmöglichkeit). Wer bearbeiten will, muss die Datei mit Hilfe des Servertools auschecken. Der Server vermerkt den Checkout und lässt keinen weiteren Checkout zu. Nach Ende der Bearbeitung checkt man wieder ein und lädt die geänderte Datei über das Servertool hoch, das sie dann in der Ablage zur Verfügung stellt. Bei der Gelegenheit kann man auch gleich das Delta zur Vorversion ermitteln, um auf ältere Versionen zurückzugelangen, man kann Änderungskommentare einfordern und vermerken, wer wann was geändert hat. Der Name dieses Servertools lautet "Versionskontrollsystem", davon gibt's eine Masse, von kostenlos bis unendlich teuer.
Es gibt auch Client-Software, die auf die Nutzung von Servertools für checkin/checkout eingestellt ist und sie automatisch ansteuert (z.B. können viele IDEs für die Softwareentwicklung automatisch mit Sourcecode-Versionskontrollsystemen interagieren, oder Microsoft Office kommuniziert automatisch mit Microsoft Sharepoint).
Rolf
-
-
Hallo allerseits,
vielen lieben Dank für eure Hilfe und Erklärungen. Das ganze sollte doch einfacher zu regeln sein, dachte ich. Mal annehmen, es gibt ein Programm/Tool in einem Unternehmen, mit dem die Mitarbeiter alle möglichen Dateien öffnen, bearbeiten und speichern können. Nun, man kann da schlecht eine bestimmte Datei, die gerade im schlimmsten Fall von mehreren Personen bearbeitet wird, einfach sperren und den anderen nicht erlauben, Ihre Änderungen zu speichern. Also da muss einen anderen Mechanismus vorhanden sein, um dieses Problem zu lösen.
Warum kann man da nicht, wie dedlfix kurz und etwas anders erwähnt hat, mehrere Kopien einer Datei erzeugen, cachen und diese dann am Ende zusammenfügen. Die Frage ist nun, wie?
Gruß
-
Hallo und guten Morgen,
Warum kann man da nicht, wie dedlfix kurz und etwas anders erwähnt hat, mehrere Kopien einer Datei erzeugen, cachen und diese dann am Ende zusammenfügen. Die Frage ist nun, wie?
In diveresen verteilten Mehrbenutzersystemen, die mit mandatory Locking arbeiten können, kann man auch einzelne Bereiche von Dateien bytegenau gegen das Lesen, Schreiben oder Lesen + Schreiben schützen.
Grouwarelösungen arbeiten oft so.
Oder nimm als Beispiel ein Netzwerk-Notepad, z. B. CollabEdit oder EtherPad. Da können auch mehrere Leute zusammen in eine Datei hineinschreiben und die anderen können dabei zusehen. Es werden sogar die unterschiedlichen Autoren farblich gekennzeichnet.
Das ist jetzt ein einfacher Anwendungsfall, der meistens auch ohne Dateisperren auskommt.
Wenn Du aber häufige Fehler vermeisen willst, dann lies den Artikel zum Filelocking.
Grüße
TS -
Tach!
Das ganze sollte doch einfacher zu regeln sein, dachte ich. Mal annehmen, es gibt ein Programm/Tool in einem Unternehmen, mit dem die Mitarbeiter alle möglichen Dateien öffnen, bearbeiten und speichern können. Nun, man kann da schlecht eine bestimmte Datei, die gerade im schlimmsten Fall von mehreren Personen bearbeitet wird, einfach sperren und den anderen nicht erlauben, Ihre Änderungen zu speichern. Also da muss einen anderen Mechanismus vorhanden sein, um dieses Problem zu lösen.
Ja, man muss die Anwendungen so programmieren, dass sie kollaboratives Arbeiten ermöglichen. Änderungen dazu müssen zwaschen den Anwendern synchronisiert werden. Zudem sollten die Anwender voneinander wissen, wenn sie gleichzeitig eine Datei bearbeiten.
Warum kann man da nicht, wie dedlfix kurz und etwas anders erwähnt hat, mehrere Kopien einer Datei erzeugen, cachen und diese dann am Ende zusammenfügen. Die Frage ist nun, wie?
Eben. Das "wie" ist entscheidend. Wie soll ein Programm feststellen/-legen, welche Änderungen diejenigen sind, die am Ende bestehen bleiben sollen? So ein Programm kann entweder nur auf eine definierte Vorgehensweise abgestimmt sein, oder es definiert von sich aus eine solche und passt dann vielleicht nicht in die Umgebung der Anwender.
Man kann aber auch mit Single-User-Programmen eine Zusammenarbeit hinbekommen. Dazu braucht man dann aber andere Vorgehensweisen und Tools. Beispielsweise dass einer dem anderen über die Schulter schaut, sie absprechen, was zu tun ist und der andere fügt die Änderungen ein. Das kann man auch mit Fernsteuerungs- und Konferenztools à la TeamViewer tun, wenn man nicht physisch zusammenkommen kann.
dedlfix.
-
Dieses Tool heißt dann gerne mal Excel oder Word. Wenn Du dort die Änderungsverfolgung einschaltest und die Datei freigibst, funktioniert das out-of-the-box. Andere Office-Pakete haben bestimmt vergleichbare Funktionen.
In einem servergestützten Versionskontrollsystem gibt's ähnliches. Da merkt sich der Versionskontrollierer welche Version Du ausgecheckt hast und man kann ihn so einstellen, dass parallele Checkouts möglich sind. Wird also z.B. Version 17 von den Usern A und B ausgecheckt, dann kann der erste (sagenwirmal A) problemlos einchecken und produziert Version 18. Wenn der zweite kommt, schlägt der Versionskontrollierer Alarm, dass man überholt worden ist. Dann ist ein Merge fällig, von dem ein gutes Merge-Tool vieles automatisch tun kann. Wurde aber an der gleichen Stelle geändert, ist ein manueller Merge fällig. Dafür muss man 3 Versionsstände vergleichen: Die gemeinsame Basis (Version 17), die Änderung von A (Version 18), und den eigenen ausgecheckten Stand. In einem vierten Fenster sieht man, wie die kommende Version 19 aussieht, die man dann einchecken kann und die bei korrektem Merge beide Änderungen integriert.
Aber sag doch mal, was du genau willst. Möchtest Du wissen, was da grundsätzlich geht, oder möchstest Du einen Mehrwege-Merge selbst programmieren?
Rolf
-