Externe Aenderungen: der Zeitstempel-Konflikt #20

New Issue

RDietermann · 2026-08-28T09:22:42Z

RDietermann commented

2026-08-28 09:22:42 +00:00

Part of #16

Question

Was tut die App, wenn sich die Datei auf der Platte geändert hat, seit sie geladen wurde?

Der Fall ist real und wird durch eine frühere Entscheidung wahrscheinlicher: Ordner-auf-Platte wurde unter anderem gewählt, weil Sync über Dropbox, Syncthing oder Git dann gratis funktioniert — und genau dieser Sync ändert Dateien, während die App läuft. Es gibt bewusst keinen Filewatcher, die App merkt es also von sich aus nicht.

Zu entscheiden:

Woran wird der Konflikt erkannt — Änderungsdatum beim Laden merken und vor dem Schreiben vergleichen, Größe, eine Prüfsumme?
Was passiert beim Speichern, wenn die Datei neuer ist: überschreiben, ablehnen, den Nutzer fragen, unter neuem Namen sichern?
Was passiert, wenn die Notiz nicht geändert wurde und die Datei sich extern ändert — stillschweigend neu laden oder stehen lassen?
Was, wenn die offene Notiz extern gelöscht wurde?

Diese Entscheidung entscheidet mit darüber, ob der ausgeschlossene Filewatcher später zur Pflicht wird: Wer den Konflikt nur beim Speichern prüft, lebt damit, dass der Nutzer bis dahin auf einem veralteten Stand arbeitet.

Zielgröße: die Erkennungsregel und eine Tabelle Fall → Verhalten.

Nachtrag aus der Recherche zu #22. Zwei belegte Punkte, die hier hineingehören:

Der Änderungszeitpunkt allein taugt nicht als Konflikterkennung. Ein Umbenennen setzt Metadaten der Zieldatei neu — bei einem nackten rename gehen Erstellungszeit und weitere Attribute sogar verloren. Wer den Konflikt nur an mtime festmacht, misst also teilweise die eigenen Schreibvorgänge mit. Zu prüfen ist deshalb, ob stattdessen der Inhalt verglichen wird (Prüfsumme des geladenen Standes), oder mtime plus Größe kombiniert.

Nebeneffekt für die Schreibfunktion: Dieses Ticket verlangt ohnehin, dass vor dem Schreiben der Zustand der Zieldatei geprüft wird. Wer dort statt eines stat gleich den Inhalt liest, hat die Vorfassung ohne zusätzlichen Syscall in der Hand — kein Grund, es heute zu tun, aber der Beleg, dass eine spätere Historie auch an dieser Stelle nichts kostet.

Part of #16 ## Question Was tut die App, wenn sich die Datei auf der Platte geändert hat, seit sie geladen wurde? Der Fall ist real und wird durch eine frühere Entscheidung wahrscheinlicher: Ordner-auf-Platte wurde unter anderem gewählt, weil Sync über Dropbox, Syncthing oder Git dann gratis funktioniert — und genau dieser Sync ändert Dateien, während die App läuft. Es gibt bewusst keinen Filewatcher, die App merkt es also von sich aus nicht. Zu entscheiden: - Woran wird der Konflikt erkannt — Änderungsdatum beim Laden merken und vor dem Schreiben vergleichen, Größe, eine Prüfsumme? - Was passiert beim Speichern, wenn die Datei neuer ist: überschreiben, ablehnen, den Nutzer fragen, unter neuem Namen sichern? - Was passiert, wenn die Notiz **nicht** geändert wurde und die Datei sich extern ändert — stillschweigend neu laden oder stehen lassen? - Was, wenn die offene Notiz extern gelöscht wurde? Diese Entscheidung entscheidet mit darüber, ob der ausgeschlossene Filewatcher später zur Pflicht wird: Wer den Konflikt nur beim Speichern prüft, lebt damit, dass der Nutzer bis dahin auf einem veralteten Stand arbeitet. Zielgröße: die Erkennungsregel und eine Tabelle Fall → Verhalten. --- **Nachtrag aus der Recherche zu #22.** Zwei belegte Punkte, die hier hineingehören: **Der Änderungszeitpunkt allein taugt nicht als Konflikterkennung.** Ein Umbenennen setzt Metadaten der Zieldatei neu — bei einem nackten `rename` gehen Erstellungszeit und weitere Attribute sogar verloren. Wer den Konflikt nur an `mtime` festmacht, misst also teilweise die eigenen Schreibvorgänge mit. Zu prüfen ist deshalb, ob stattdessen der **Inhalt** verglichen wird (Prüfsumme des geladenen Standes), oder mtime plus Größe kombiniert. **Nebeneffekt für die Schreibfunktion:** Dieses Ticket verlangt ohnehin, dass vor dem Schreiben der Zustand der Zieldatei geprüft wird. Wer dort statt eines `stat` gleich den Inhalt liest, hat die Vorfassung ohne zusätzlichen Syscall in der Hand — kein Grund, es heute zu tun, aber der Beleg, dass eine spätere Historie auch an dieser Stelle nichts kostet.

RDietermann added the wayfinder:grilling label 2026-08-28 09:22:42 +00:00

RDietermann referenced this issue

2026-08-28 10:27:32 +00:00

Was kostet es, Historie spaeter moeglich zu halten? #22

RDietermann referenced this issue

2026-08-28 10:51:05 +00:00

Notiz-Handling: anlegen, speichern, umbenennen, loeschen #16

Sign in to join this conversation.