From 035923834bfdc91057c4bce1a00cd2b3236d033e Mon Sep 17 00:00:00 2001 From: Stefan Hacker Date: Sun, 12 Apr 2026 11:36:07 +0200 Subject: [PATCH] docs: README erklaert Reichweite des File Locks in Alltagssprache Neuer Abschnitt "Was das Lock wirklich kann (und was nicht)" mit Tabelle + Beispielszenario Adam/Anna. Zeigt Laien, dass das Lock Web-GUI, Client und Upload schuetzt, aber nicht den Windows- Explorer - und dass die Konflikt-Kopie das Sicherheitsnetz ist. Co-Authored-By: Claude Opus 4.6 (1M context) --- README.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/README.md b/README.md index 8fdd0b7..64a0f91 100644 --- a/README.md +++ b/README.md @@ -359,6 +359,30 @@ Dateien werden beim Oeffnen ueber den Client automatisch auf dem Server gesperrt | Laptop zugeklappt / Netzwerk weg | Kein Heartbeat -> Lock laeuft nach 15 Min ab | | Admin im Web-UI | Kann jeden Lock jederzeit manuell loesen | +#### Was das Lock wirklich kann (und was nicht) + +Das Auschecken ist ein **Hinweis-Schloss**, kein physikalisches Dateischloss. Kurz gesagt: es hindert alle **Mini-Cloud-Wege** am Bearbeiten, aber nicht den Windows-Explorer oder andere Programme auf der Festplatte. + +| Wo greift das Lock? | Beispiel | +|---------------------|----------| +| ✅ Web-Oberflaeche | Anna kann im Browser die Datei nicht oeffnen/bearbeiten - "wird von Adam bearbeitet" | +| ✅ Desktop-Client | Doppelklick in der Client-Ansicht -> Fehlermeldung, Datei oeffnet nicht | +| ✅ Automatischer Upload | Hat Anna die Datei trotzdem editiert, hebt der Client sie nicht hoch, solange Adam das Lock haelt | +| ❌ Windows-/Mac-Explorer | Anna kann die lokale Datei im Dateimanager oeffnen (ist ja eine ganz normale Datei auf der Platte) | +| ❌ Externe Programme | Word, Excel, Notepad usw. sehen das Lock nicht - jedes Programm kann die Datei oeffnen | + +**Beispiel im Alltag:** + +1. Adam checkt `Bericht.xlsx` aus (oeffnet sie im Client) +2. Anna hat den Ordner auch gesynct und die Datei liegt bei ihr lokal +3. Anna versucht, sie im Browser zu oeffnen -> **blockiert** +4. Anna versucht, sie im Client zu oeffnen -> **blockiert** +5. Anna oeffnet sie im Explorer direkt -> **geht auf** (weil die Datei technisch ja nur eine normale Datei ist) +6. Anna bearbeitet und speichert lokal -> Client bemerkt die Aenderung, sieht das Fremd-Lock und **haelt den Upload zurueck** +7. Adam checkt ein: jetzt vergleicht der Client - hat Adam auch geaendert? Wenn ja, wird Annas Version zu `Bericht (Konflikt Anna 2026-04-12 143022).xlsx` und Adams Version gewinnt. Niemand verliert Daten, aber ein Mensch muss die Versionen zusammenfuehren. + +Das ist derselbe Ansatz wie bei Nextcloud oder Dropbox: **Konflikt-Kopie als Sicherheitsnetz**, keine kernel-tiefe Dateisperre. Der Schutz kommt ueber die Upload-Sperre - damit landet ein versehentliches Bearbeiten nie beim eigentlichen Owner. + ### Bauen ```bash