nicht angemeldet
Tach!
Einziges Problem ist, dass dann das komplette Programm auf "von vorn beginnen" eingerichtet werden muss. Denn mit den eingelesenen Daten geschieht ja etwas, sie werden im ganzen Programm verteilt.
Vermutlich nicht komplett. Ich weiß nicht, was genau du mit den Daten anstellst, aber meist ist es doch nur ein Lesen für einen einzigen Request mit anschließendem Verwerfen neben allen anderen Daten am Requestende. Und wieder nur ein Lesen für den nächsten Request, usw. Ändern kommt üblicherweise nur recht selten vor. Das "von vorn beginnen" beschränkt sich also auf den Fall, das jemand was ändern will.
Webbasierte Bearbeitung findet ja in mehreren Prozessen statt. [...] Dieses TOCTTOU-Problem zu lösen, geht mit Dateisperen allein nicht mehr. Da braucht es auch noch einen Zeitstempel oder ein ähnliches eindeutiges Merkmal (Checksum), um die Originalität der Daten vor dem Ändern zu prüfen.
Dieses Problem ist mir durchaus bewusst. Es liegt allerdings mMn. auf einem höheren Abstraktionslayer.
Ja, aber diesen Fall musst du am Ende auch noch lösen, zusätzlich zu den Parallelitätsproblemen beim eigentlichen Datei-Schreibvorgang.
Beginnt ein Benutzer eine Datei zu editieren, wird ihm der Zeitstempel des letzten Edits mitgegeben. Wenn er speichert, wird anhand des Zeitstempels (oder einer Versionsnummer, etc.) überprüft, ob die Datei inzwischen noch einmal geändert wurde. Wenn ja, bekommt der Benutzer eine Fehlermeldung und den Hinweis, er solle doch bitte seine Änderungen an die neue Version der Datei anpassen.
Dieser Mechanismus erfordert allerdings die Lösung des von mir angesprochenen Problems mit Dateisperren, oder?
Nur für den eigentlichen Schreibvorgang. Du musst ja selbst für die Zeitstempelprüfung (und dem potentiellen nachfolgenden Schreiben) nach dem Formularabsenden sicherstellen, dass nicht innerhalb deines Prozesses ein anderer Prozess querschießt.
Datenbankbasiert könnte man ein UPDATE ..., timestamp=NOW() WHERE id=$id AND timestamp=$old_timestamp loslassen. Wurde dann ein Datensatz geändert, war alles bestens und man ist schon fertig. Nur bei 0 affected rows gab es ein Problem mit zwischenzeitlicher Fremdbearbeitung. UPDATE ist ein atomarer Prozess, dafür sorgt das DBMS, da muss man sich nicht noch um weitere Sperren kümmern, die zwischen Lesen zwecks Ermitteln des aktuellen Timestamps für die Prüfung und Schreiben eine Parallelbearbeitung verhindern. Letzteres musst du aber bei dateibasiertem System mit Dateisperren selbst implementieren. Damit hast du dann zwei Abbruchbedingungen: einmal der geänderte Timestamp und dann das Misslingen des Schreibens, weil der EX nicht nahtlos nach dem SH zu bekommen war.
dedlfix.