Vollstaendige CalDAV-Implementierung unter /dav/ - Thunderbird,
DAVx5, Apple Calendar und Outlook (CalDAV-Synchronizer) koennen
sich einfach ueber HTTP-Basic-Auth mit ihrem Mini-Cloud-Account
anmelden und ihre Kalender synchronisieren.
Unterstuetzte Methoden:
* OPTIONS - DAV-Capabilities
* PROPFIND - Discovery, Principal, Calendar-Home, Kalender,
Termin-Listings (Depth 0/1 beachtet)
* REPORT - calendar-query + calendar-multiget mit
optionalem Zeitraumfilter (<time-range>)
* GET - einzelner Termin als VCALENDAR
* PUT - Termin erstellen/aktualisieren (mit ETag-Check
via If-Match + If-None-Match)
* DELETE - Termin oder ganzer Kalender
* MKCALENDAR - neuen Kalender vom Client aus anlegen
iCal-Parser verarbeitet SUMMARY, DESCRIPTION, LOCATION, DTSTART,
DTEND, RRULE, EXDATE - inklusive Line-Folding (RFC 5545).
Ganztages-Termine (VALUE=DATE) werden korrekt erkannt.
ETags basieren auf updated_at-Zeitstempel und werden pro
PUT-Response zurueckgegeben, damit Clients Konflikte erkennen.
nginx.example.conf: /dav/ mit proxy_request_buffering off fuer
groessere PUTs und Weiterleitung der .well-known-URLs.
README: eigener "CalDAV-Zugriff"-Block mit Tabelle pro Client.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
eventDisplay: 'block' zwingt FullCalendar dazu, auch zeitlich
terminierte Termine in der Monatsansicht als farbige Balken
anzuzeigen statt als Punkt mit Uhrzeit-Label. Damit sieht ein
per "Neuer Termin"-Button angelegter Termin genauso aus wie einer,
der per Klick auf den Tag erstellt wurde.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Klick auf einen wiederkehrenden Termin oeffnet zuerst einen Dialog:
"Nur diesen Termin" oder "Ganze Serie".
* Serie: bearbeitet den Master wie bisher
* Nur dieser: fuegt EXDATE fuer das geklickte Datum zum Master
hinzu und legt einen eigenstaendigen Ersatz-Termin mit den
bearbeiteten Daten an
Backend:
* CalendarEvent.exdates speichert Ausnahmedaten kommasepariert
* POST /events/<id>/exception fuegt EXDATE hinzu, erstellt
optional das Replacement-Event mit frischer UID
* _build_vevent schreibt jetzt EXDATE-Zeilen in die ical_data,
sodass CalDAV-Clients die Ausnahmen auch sehen werden
Frontend:
* FullCalendar rrule-Plugin bekommt die exdate-Liste und blendet
die uebersprungenen Tage aus
* Drag & Drop verschiebt weiterhin die ganze Serie (Shortcut -
fuer Einzelverschiebung Termin anklicken und bearbeiten)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* 📅-Icon bei ganztaegigen Terminen
* 🔁-Icon bei wiederkehrenden Terminen
* Anzeige "09:00-10:30" statt nur "09:00" in Woche/Tag-Ansicht
* Mouseover-Tooltip mit allen Termin-Infos inklusive Ort und
Beschreibung
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Neben der Muelltonne jetzt ein Stift-Icon im Share-Dialog:
Klick macht die Zeile zur Inline-Edit-Zeile mit Permission-
Dropdown + Weiterteilen-Checkbox + Speichern/Abbrechen-Buttons.
Speichern ruft POST /permissions mit user_id auf - Backend
erkennt die bestehende Freigabe und aktualisiert sie, statt
loeschen + neu anlegen zu muessen.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Backend:
set_permission und remove_permission feuern jetzt ein SSE-Event vom
Typ 'permission' an Target-User + Owner + weitere Share-Empfaenger.
Damit aktualisieren sich die Dateilisten aller Beteiligten in
Echtzeit - auch beim Betroffenen, der gerade seinen Zugriff
verliert.
Frontend:
FilesView wrapped loadFiles in safeLoadCurrentFolder(). Bei
403/404 erscheint ein Toast "Dieser Ordner wurde geloescht oder
die Freigabe wurde entfernt" und nach 600ms wird zurueck zum
Root navigiert. Greift beim Direktaufruf, beim Ordnerwechsel und
bei durch SSE ausgeloesten Auto-Reloads.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Neues Berechtigungs-Modell fuer Benutzerfreigaben:
* FilePermission bekommt zwei neue Spalten:
- can_reshare (bool): darf dieser Nutzer die Freigabe weiterverteilen?
- granted_by (user_id): wer hat diese Freigabe erstellt?
* set_permission / create_share_link erlauben jetzt auch Nicht-Owner,
sofern sie can_reshare haben. Dabei gilt:
- Lesend + reshare -> kann nur lesend weiterteilen
- Schreibend + reshare -> kann lesend ODER schreibend weiterteilen
- Admin kann nur der Eigentuemer vergeben
- Jeder Re-Sharer kann wiederum can_reshare weitergeben
* remove_permission: Owner kann alle Freigaben entfernen; Re-Sharer
nur die von ihnen selbst erstellten.
* get_permissions: Owner sieht alle; Re-Sharer nur selbst-erstellte.
* list_files liefert my_permission + my_can_reshare pro Eintrag -
Frontend kann Rename/Delete/Share-Buttons gezielt ein- und
ausblenden statt blind alle anzuzeigen.
Frontend:
* Rename/Delete-Buttons nur fuer Write-Zugriff
* Share-Button nur fuer Owner oder Re-Sharer
* "darf weiterteilen" Checkbox neben Permission-Dropdown im Dialog
* Dropdown-Optionen nach eigenem Level gefiltert (Re-Sharer sieht
keine hoeheren Stufen als seine eigene)
* Hinweis-Text "Du hast X - du kannst maximal X weiterteilen"
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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) <noreply@anthropic.com>
Die lokale Dateiliste im Client zeigt jetzt pro Datei ein 🔒-Badge
mit Nutzername wenn ausgecheckt (wie Server-Ansicht + Web-GUI).
browse_sync_folder zieht den Server-Tree bei jedem Aufruf und
korreliert via Journal-Lookup (oder .cloud-Metadaten) die lokale
Datei mit dem File-Lock-Status.
Rechtsklick-Menue reagiert jetzt auf den Lock-Status:
- Frei -> "Auschecken (sperren)"
- Eigener/fremder -> "Entsperren (einchecken)"
Neuer Tauri-Command lock_file_cmd fuer reines Sperren ohne Oeffnen.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Beim Verbindungsaufbau (open-Event) wird jetzt ein initialer Reload
ausgeloest, damit eventuelle Changes in der Zeit zwischen letzter
Anzeige und SSE-Verbindung nicht verloren gehen. Gilt fuer eigene
und freigegebene Ordner gleichermassen (selbe FilesView-Komponente).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Die Server-Dateiliste im Client wartete bisher auf einen abgeschlossenen
Sync-Durchlauf, bevor Lock-Aenderungen anderer Nutzer sichtbar wurden.
Ausloeser von Events ohne Datei-Download (reine Lock/Unlock-Events)
landeten teils gar nicht in der UI.
Frontend hoert jetzt direkt auf das sse-event vom Backend und ruft
loadFileTree + loadLocalFiles auf - damit Lock-Icons im Server-Tree
in Echtzeit erscheinen/verschwinden.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Bisher hat der Client nur beim ersten Oeffnen (.cloud-Platzhalter ->
Download) gesperrt. Nach dem Einchecken und erneutem Doppelklick
blieb die Datei ungesperrt, weil der Open-Pfad fehlte.
Neuer Tauri-Command open_offline_file loest die Server-Datei-ID
ueber das Sync-Journal auf, sperrt auf dem Server und oeffnet
lokal mit der Standard-App. Im lokalen Dateibrowser:
- Doppelklick auf eine bereits offline vorhandene Datei checkt sie
nun aus und oeffnet sie (vorher: keine Reaktion)
- Rechtsklick-Menue hat "Oeffnen (auschecken)" fuer Offline-Dateien
Das Lock triggert wie gehabt notify_file_change -> SSE -> Web-UI
aktualisiert den Lock-Status sofort.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
/files/<id>/save (Text/HTML/Spreadsheet) und der OnlyOffice-
Callback aktualisierten Inhalt + Checksum, riefen aber
notify_file_change nicht auf. Der Client bekam dadurch keinen
SSE-Trigger und merkte die neue Server-Version erst beim naechsten
30s-Fallback-Sync - wenn ueberhaupt.
Jetzt: beide Endpoints emittieren 'updated' an Owner + Share-
Empfaenger, Desktop- und Web-Clients reagieren sofort.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Mit 2 Gunicorn-Workern laeuft der In-Memory-Broadcaster in zwei
voneinander getrennten Prozessen. Landet ein Lock-Request auf
Worker A und die SSE-Verbindung des Empfaengers auf Worker B, kommt
das Event nie beim Client an - genau deshalb klappte der Live-
Refresh bei freigegebenen Ordnern nicht zuverlaessig.
Jetzt: 1 Worker mit 32 Threads. Threads teilen Memory, der
Broadcaster ist fuer alle Verbindungen derselbe. Fuer mehr Durchsatz
waere Redis Pub/Sub noetig - hier reicht aber Single-Process-Modus.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Mit 4 synchronen Workern hielt jede SSE-Verbindung dauerhaft einen
ganzen Worker besetzt. 4 offene Browser-Tabs -> alle anderen
Requests blockiert -> "Dateien laden dauert ewig".
Loesung: gthread worker-class mit 2 Workern x 16 Threads = 32
gleichzeitige Slots. Lang laufende SSE-Streams belegen nur je
einen Thread, regulaere Requests laufen unbeeintraechtigt.
nginx.example.conf: separater Location-Block fuer /api/sync/events
mit proxy_buffering off und 24h Read-Timeout, damit die Events
sofort durchkommen und die Verbindung nicht abbricht.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Drei Probleme in einem:
1. create_folder/get_sync_tree parsten die Response auch bei HTTP-
Fehlern als JSON. Bei 401/409/etc. kam "error decoding response
body" statt der eigentlichen Fehlermeldung. Status wird jetzt
zuerst geprueft, Body-Text wird bei Fehlern zurueckgegeben.
2. Ohne Journal-Eintrag und unterschiedlichen Hashes wurde vorher
eine Konflikt-Kopie erstellt. Fuer Server-Edits aus dem Web-UI
(wo der Client die Datei gar nie mit Journal erfasst hatte) war
das falsch. Nextcloud-Ansatz: beim Erstkontakt Server
autoritativ - Download statt Konflikt-Kopie.
3. run_sync_now uebernimmt neu konfigurierte sync_paths aus dem
State, damit manuelle Syncs auch nach add_sync_path greifen.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
FilesView abonniert beim Mount die SSE-Events des Backends. Lock/
Unlock, Create, Update oder Delete durch andere Clients loest einen
debounced Reload der aktuellen Ordner-Ansicht aus. EventSource
reconnected automatisch; wird beim Unmount sauber geschlossen.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
list_files filterte Kinder-Dateien nach owner_id=current_user, wodurch
in einem freigegebenen Ordner (der einem anderen User gehoert) keine
Dateien angezeigt wurden. Jetzt wird beim Betreten eines Ordners die
Zugriffsberechtigung geprueft; bei eigenem Ordner wie gehabt, bei
freigegebenem Ordner werden alle Kinder-Dateien gelistet.
_check_file_access laeuft jetzt auch den Ordner-Baum hoch, damit
eine Permission auf einem Vorfahren-Ordner automatisch Zugriff auf
alle Nachkommen gewaehrt.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
apiClient hat baseURL '/api' - die URL darf nicht nochmal mit /api
anfangen, sonst wird daraus /api/api/... und der Request geht ins
Leere.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Temporary-Drop-Order: MutexGuard hielt Referenz auf State-Binding,
das am Block-Ende schon fallen gelassen wurde. Zwischenvariable
erzwingt Drop der MutexGuard vor dem Binding.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Download-Endpoint unterstuetzt jetzt ?inline=1, wodurch
Content-Disposition auf inline statt attachment gesetzt wird.
PDF- und Bild-Preview nutzen diesen Parameter, damit der
Browser das PDF im Preview-Iframe rendert statt einen Download
auszuloesen. Normale Download-Buttons bleiben unveraendert.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Desktop-Client komplett ueberarbeitet nach Nextcloud-Vorbild:
- Persistentes SQLite-Journal (journal.rs) speichert letzten bekannten
Stand pro Datei - ueberlebt Client-Neustarts (Hauptbug behoben).
- Engine.rs neu: 3-Wege-Vergleich Local <-> Journal <-> Server mit
sauberer Konflikt-Kopie (inkl. Username + Zeitstempel).
- Loesch-Propagation: Lokal geloeschte Dateien landen im Server-
Papierkorb des Owners (auch bei Freigaben). Auf dem Server
geloeschte Dateien werden lokal entfernt.
- Lock-Flow repariert: frischer Token bei jedem Call, Fehler-Feedback.
Echtzeit-Sync:
- Backend: SSE-Endpoint /api/sync/events mit In-Memory-Broadcaster.
Events bei Create/Update/Delete/Lock/Unlock, Zustellung an Owner
plus alle User mit Share-Permission.
- Client: persistente SSE-Verbindung mit Auto-Reconnect. Events
triggern sofortigen Sync (<100ms). 30s-Polling bleibt als
Fallback fuer Netzwerk-Aussetzer.
Weitere Fixes:
- /api/sync/tree filtert is_trashed=False (Papierkorb wird nicht
mehr an Clients gesynct).
- Web-GUI: Lock/Unlock-Buttons pro Datei, Admin darf fremde Locks
zwangsweise loesen. Rename/Delete disabled bei fremdem Lock.
- Lock-Check im Backend bei PUT/DELETE (423 Locked Response).
- Background-Sync nur noch einmal pro Prozess gestartet, liest
sync_paths pro Iteration neu - add/remove wirkt sofort, kein
Client-Neustart mehr noetig.
- Watcher werden pro Sync-Pfad individuell verwaltet.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Wenn jemand vergisst zu entsperren:
- Client laeuft -> Heartbeat alle 60s -> Lock bleibt aktiv
- Client geschlossen -> kein Heartbeat -> Lock laeuft nach 15 Min ab
- Laptop zugeklappt -> gleicher Effekt -> 15 Min -> frei
Tracking: locked_files Vec merkt sich welche Dateien wir gesperrt haben.
Heartbeat laeuft im Token-Refresh Thread mit (alle 60s Heartbeat,
alle 10 Min Token-Refresh).
Lock wird beim Oeffnen getrackt, beim Entsperren/Unmark-Offline entfernt.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Beim Oeffnen einer .cloud-Datei:
- Download + Datei bleibt lokal (wie bisher)
- Lock wird auf dem Server gesetzt (andere sehen "gesperrt von X")
- Kein Auto-Unlock - Datei bleibt gesperrt bis manuell entsperrt
Rechtsklick im Datei-Browser auf Offline-Dateien:
- "Entsperren (Freigeben fuer andere)" - hebt den Lock auf
- "Nicht mehr offline" - .cloud zurueck + automatisch unlock
So bleiben Dateien gesperrt solange man daran arbeitet.
Wenn fertig: Rechtsklick -> Entsperren. Einfach und explizit.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Problem: Notepad und die meisten Editoren halten keinen File-Lock.
is_file_in_use() fand sofort "nicht in Benutzung" und raeumte die
Datei auf bevor der User sie bearbeiten konnte.
Neuer Ansatz - drei Bedingungen muessen erfuellt sein:
1. Mindestens 30 Sekunden seit dem Oeffnen (Schutzzeit)
2. Kein File-Lock UND Dateigroesse unveraendert
3. Mindestens 2 Minuten seit der letzten Aenderung/Lock
Datei-Aktivitaet wird getrackt:
- Groesse aendert sich -> Timer zuruecksetzen
- File-Lock aktiv (Office) -> Timer zuruecksetzen
- Erst nach 2 Minuten Inaktivitaet -> Auto-Close
So funktioniert es fuer alle Programme:
- Office (haelt Lock): Lock verschwindet -> 2 Min warten -> Close
- Notepad (kein Lock): Letzte Groessenaenderung -> 2 Min -> Close
- Schnell oeffnen+schliessen: 30s Schutzzeit verhindert sofortiges Close
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Vorher: Platzhalter wurde nur erstellt wenn er nicht existierte.
Wenn sich die Datei auf dem Server aenderte (neue Groesse, neuer
Checksum), blieb der Platzhalter mit den alten Metadaten.
Jetzt: Bei jedem Sync wird der Checksum im Platzhalter mit dem
Server-Checksum verglichen. Bei Unterschied -> Platzhalter neu
schreiben mit aktueller Groesse, Checksum und Datum.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Dateiname: Erst aus JSON "name" Feld, Fallback: .cloud von Dateiname strippen
- Alle Fehler werden jetzt gemeldet statt verschluckt (download, lock, open)
- open::that Fehler wird zurueckgegeben statt ignoriert
- Ausfuehrliches Logging: Pfade, Groesse, Lock-Status
- Pruefung ob Download-Datei existiert bevor geoeffnet wird
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Kann nicht &self.sync_paths iterieren und gleichzeitig &mut self
Methoden aufrufen. Clone der Liste loest den Konflikt.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Problem: Timestamps waren unzuverlaessig fuer die Sync-Richtung
(Download setzt lokale mtime auf 'jetzt', Timezone-Differenzen).
Offline-markierte Dateien wurden nie vom Server aktualisiert.
Loesung: known_checksums HashMap trackt den Server-Checksum
beim letzten Sync. Bei unterschiedlichen Checksums:
| Lokal geaendert | Server geaendert | Aktion |
|-----------------|------------------|--------|
| Nein | Ja | Server->Lokal (Download) |
| Ja | Nein | Lokal->Server (Upload) |
| Ja | Ja | KONFLIKT (lokale Kopie umbenennen, Server runterladen) |
Erster Sync (kein known_checksum): Server gewinnt immer (Download).
Danach wird jeder Server-Checksum gespeichert.
Betrifft: sync_virtual, sync_upload_new, sync_full_upload
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Server->Client Sync:
- Server sendet Timestamps ohne Timezone (2026-04-11T12:49:24.735436)
- parse_from_rfc3339 braucht Timezone -> schlug still fehl
- Client dachte IMMER er sei neuer -> Upload statt Download
- Fix: parse_server_time() akzeptiert beides (mit/ohne Timezone)
- Probiert RFC3339, dann NaiveDateTime mit Microseconds, dann ohne
File Locking:
- open_cloud_file nutzte API-Clone vom SyncEngine (evtl. alter Token)
- Jetzt direkt state.api (immer aktueller Token nach Refresh)
- Lock wird zuverlaessig gesetzt beim Oeffnen von .cloud Dateien
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Von der ersten Zeile Code bis zum Desktop Sync Client.
9 Versionen, 70+ Commits, alles an einem Tag.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- .cloud Doppelklick oeffnet Datei im Hintergrund ohne das Client-
Fenster aufzupoppen (war nervig)
- Neue Einstellung "Minimiert starten (direkt im System-Tray)"
als Checkbox im Einstellungen-Bereich
- Wird in config.json gespeichert, bleibt bei Updates erhalten
- Bei aktiviertem Haken: Client startet unsichtbar im Tray,
Sync laeuft im Hintergrund, Fenster nur per Tray-Doppelklick
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Problem: Lock verschwand nach 5 Minuten weil:
1. JWT-Token nach 15 Min ablief -> Heartbeat schlug still fehl
2. Server gab Lock nach 5 Min ohne Heartbeat frei
Fix Client:
- Token-Refresh alle 10 Minuten (vor dem 15-Min-Ablauf)
- Aktualisiert den Token in der shared API-Instanz
- Heartbeat nutzt immer den aktuellen Token
Fix Backend:
- Lock-Timeout von 5 auf 15 Minuten erhoeht
- Genug Puffer fuer Netzwerk-Probleme oder kurze Unterbrechungen
Timeline:
0s -> Lock + Heartbeat alle 10s
600s -> Token-Refresh
900s -> Lock wuerde erst jetzt ablaufen (15 Min ohne Heartbeat)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Problem: Nach Oeffnen einer .cloud-Datei blieb die Sperre auf dem
Server bestehen, auch wenn Word/Excel geschlossen wurde.
Loesung: Hintergrund-Thread prueft alle 10 Sekunden ob geoeffnete
Dateien noch von einem Prozess benutzt werden:
Windows: Versucht exklusiven Schreibzugriff - wenn erfolgreich ist
die Datei nicht mehr in Benutzung (Office gibt den Lock frei)
Linux/Mac: lsof prueft ob ein Prozess die Datei offen hat
Wenn Datei geschlossen:
1. Aenderungen werden zum Server hochgeladen
2. Server-Lock wird aufgehoben
3. .cloud Platzhalter wird neu erstellt (mit aktuellem Checksum)
4. Lokale Kopie wird geloescht
5. UI zeigt "Geschlossen + entsperrt: datei.cloud"
Tracking: opened_files HashMap speichert file_id -> Pfad + Cloud-Name
fuer alle via .cloud geoeffneten Dateien.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Problem: Wenn eine Datei auf dem Server geaendert wurde, hat der
Client sie trotzdem mit der lokalen (alten) Version ueberschrieben.
Der Sync hat nur Checksums verglichen aber nicht geprueft wer neuer ist.
Fix: Bei unterschiedlichen Checksums wird jetzt der Timestamp verglichen:
- Server neuer (updated_at > lokales modified) -> Download vom Server
- Lokal neuer (modified > Server updated_at) -> Upload zum Server
- Log zeigt "Server->Lokal" oder "Lokal->Server" statt nur "Aktualisiert"
Betrifft alle drei Sync-Methoden:
- sync_virtual (Offline-markierte Dateien)
- sync_upload_new (Virtual Mode Upload)
- sync_full_upload (Full Sync Upload)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Features-Liste (Virtual Files, Multi-Sync, Offline, Locking, Tray etc.)
- Terminalserver-Tabelle (pro User eigene Instanz)
- Virtual Files vs. Full Sync Vergleichstabelle
- Einstellungen-Pfade pro OS
- Config bleibt bei Updates erhalten
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Lock-File liegt in %APPDATA% (Windows) bzw ~/.config (Linux) -
das ist pro User verschieden. Auf Terminalservern kann jeder
User seine eigene Instanz haben.
Verbesserungen:
- Prueft ob der Prozess aus dem Lock-File noch lebt (PID-Check)
statt nur ob die Datei existiert
- Windows: tasklist /FI "PID eq X"
- Linux: /proc/PID existiert?
- Stale Lock-Files (Prozess abgestuerzt) werden ueberschrieben
- Ohne .cloud Argument + andere Instanz laeuft -> sofort beenden
- Mit .cloud Argument + andere Instanz -> delegieren und beenden
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Config-Persistenz:
- Passwort wird base64-kodiert in config.json gespeichert
(statt OS-Keyring der beim Cross-Compile nicht funktioniert)
- Config-Pfad wird beim Laden/Speichern geloggt fuer Debugging
- Keyring-Dependency entfernt, base64 hinzugefuegt
Single-Instance:
- Lock-File in Config-Dir verhindert doppelte Instanz
- Wenn .cloud Datei doppelgeklickt wird und Client laeuft:
Pfad wird in open_request.txt geschrieben und 2. Instanz beendet sich
- Laufende Instanz pollt open_request.txt und oeffnet die Datei
- Fenster wird automatisch in den Vordergrund geholt
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Nutzt default_window_icon() statt Image::from_bytes das in
dieser Tauri-Version nicht existiert.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Settings-Persistenz:
- Config wird in OS-AppData gespeichert
(Windows: %APPDATA%/MiniCloud Sync/config.json,
Linux: ~/.config/MiniCloud Sync/config.json,
Mac: ~/Library/Application Support/MiniCloud Sync/config.json)
- Gespeichert werden: Server-URL, Username, Sync-Pfade
- Passwort wird im OS-Keychain gespeichert (Windows Credential Manager,
macOS Keychain, Linux Secret Service) - nicht in der Config-Datei
Auto-Login:
- Beim Start wird gespeicherte Config geladen
- Wenn Credentials im Keychain vorhanden: automatischer Login
- Wenn Sync-Pfade konfiguriert: Sync startet sofort automatisch
- Bei Fehler: Login-Screen mit vorausgefuellten Feldern
Config ueberlebt Updates:
- Config liegt ausserhalb des Installationsverzeichnisses
- NSIS-Installer ueberschreibt nur App-Dateien, nicht AppData
- installMode: "both" erlaubt per-User und per-Machine Installation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Problem: Im Virtual Mode wurden nur .cloud Platzhalter fuer
Server-Dateien erstellt, aber neue lokale Dateien wurden nie
hochgeladen. Der Watcher hat die Aenderung erkannt aber der
Sync hat sie ignoriert.
Fix: sync_upload_new() wird jetzt auch im Virtual Mode aufgerufen.
Scannt den lokalen Ordner nach Dateien die auf dem Server nicht
existieren und laedt sie hoch. Auch geaenderte lokale Dateien
(Checksum-Vergleich) werden aktualisiert. Gesperrte Dateien
werden zurueckgehalten.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Datei-Browser im Client:
- Zeigt lokalen Sync-Ordner mit allen Dateien an
- Ordner navigierbar mit Breadcrumb
- Status pro Datei: ☁ Cloud (Platzhalter) / 📄 Offline (echte Datei)
- Badges: blaues "Cloud" oder gruenes "Offline"
- Cloud-Dateien zeigen Originalgroesse aus .cloud-Metadaten
- Aktualisiert sich automatisch nach jedem Sync
Rechtsklick-Kontextmenue:
- .cloud Datei: "Oeffnen (herunterladen)" + "Offline verfuegbar machen"
- Echte Datei: "Nicht mehr offline (Platzhalter)"
- Doppelklick auf Ordner = navigieren
- Doppelklick auf .cloud = herunterladen + oeffnen
Rust-Backend:
- browse_sync_folder: Listet lokale Dateien mit Status auf
(is_cloud, is_offline, cloud_size aus JSON-Metadaten)
- Sortierung: Ordner zuerst, dann alphabetisch
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Stefan Hacker