Eigentlich arbeitet der Filter auf den Pfaden inkl. Dateinamen. D.h. du kannst beliebig Dinge filtern. Siehe hier: SyncDropbox/module.php at master · paresy/SyncDropbox · GitHub
paresy
Habe ich den Code so falsch verstanden?
$files = scandir($baseDir . $dir);
foreach ($files as $file) {
if ($file == '.' || $file == '..') {
//Ignore special folders
} elseif (is_dir($baseDir . $dir . $file)) {
$searchDir($dir . $file . '/');
} else {
if (!$this->IgnoreFile($dir . $file)) {
$touchedFiles[] = mb_strtolower('/' . $this->GetDestinationFolder() . '/' . $dir . $file);
wenn is_dir(), dann gehe rekursiv in das Verzeichnis, nur denn kein is_dir(), dann IngnoreFile()-Check?
Ich hätte mal genauer schauen sollen. Ich fixe das - das war früher mal anders und korrekter.
paresy
1 „Gefällt mir“
Theoretisch sollte das doch funktioniert haben. In „IgnoreFile“ wird ja der ganze Pfad angegeben und der Check prüft quasi den Filter von vorne (siehe SyncDropbox/module.php at master · paresy/SyncDropbox · GitHub). D.h. wenn du „webfront/user“ angibst, sollte er korrekt alles in diesem Ordner weglassen.
Ich habe aber mal den Code umgebaut, damit man diesen besser lesen kann. Und die Funktion auch FilterPath genannt, da dies besser den Einsatzzweck beschreibt.
Neue Beta jetzt verfügbar.
paresy
kann ich logs und DB einfach Filtern? Dropbox soll nur das absolut Notfall backup bei mir sein, das die Konfig nach vorhanden ist falls das Haus explodiert.
wobei eine Komprimierung für die Log Dateien wäre natürlich viel besser. Die sind gepackt vermutlich nur noch ein paar MB groß.
könnte man sowas nicht einbauen 
?
Danke, probier ich aus
Die logs sind unter Windows automatisch im Filter drin. Wenn du „db“ in den Filter schreibst, sollte auch die DB gefiltert werden.
paresy
geht das Dropbox Modul auch, wenn ich IPS in einem Proxmox Container (Ubuntu) habe oder ist das eher ausgelegt nur für Windows User?
VG
Stefan
Ich habe IPS unter Proxmox laufen, das funktioniert Betriebssystem-unabhängig
So dachte ich mir das auch. Habe seit gestern bei mir das Modul am laufen und er ist immer noch am syncen.
Habe das Modul nun gerade als beta installiert.
Konnte Konfigurationsform nicht laden
Habe den Filter eingetragen, mich in Dropbox angemeldet.
Dann passierte erstmal nix, die zugeordneten Timer waren inaktiv.
Dann habe ich die Instanz Aktiv auf Nein und dann wieder auf Ja geschaltet, damit wurde der zugeordnete Timer _Sync" aktiv.
Er erzählte was von Upload beginnt in 10 Sekunden (oder so ähnlich).
Im Debug war nichts zu sehen.
Ich hatte versehentlich die Instanz-Konfiguration geschlossen. Bei erneuten Öffnen kommt diese Meldung
Warning: gzdecode(): data error in /var/lib/symcon/modules/.store/de.paresy.sync.dropbox/SyncDropbox/module.php on line 360 Fatal error: Uncaught TypeError: json_decode() expects parameter 1 to be string, bool given in /var/lib/symcon/modules/.store/de.paresy.sync.dropbox/SyncDropbox/module.php:360 Stack trace: #0 /var/lib/symcon/modules/.store/de.paresy.sync.dropbox/SyncDropbox/module.php(360): json_decode(false, true) #1 /-(3): SyncDropbox->GetConfigurationForm() #2 {main} thrown in /var/lib/symcon/modules/.store/de.paresy.sync.dropbox/SyncDropbox/module.php on line 360 (Code: -32603)
Im Debug stand nur mehrfach, das der Token noch ok ist bis … und dann war ruhe.
Im Dropbox selbst ist nix passiert.
Ok, Instanz gelöscht, erneut eingerichtet (erstmal ohne Filter) → alles ok.
Es erschien die Größe des Backups (9.x GB), die laufende ProgressBar und die Ankündigung, das es nach 10 Sekunden losgeht.
Ging aber nicht.
Dann werde den Filter eingetragen (/webfront/user/netatmo) … und dann kommt wieder die o.g. Fehlermeldung.
Passieren tut weiterhin nichts.
In meinem Testsystem hatte ich vor 2 Wochen oder so die stable aktiviert, die ging und in der Dropbis wurde der passender Ordner (Apps/Symcon/) gefüllt…
Ich habe den Code mal angepasst
if ($this->GetBuffer('FileQueue') != '') {
$buf = @gzdecode($this->GetBuffer('FileQueue'));
if ($buf != false) {
$fileQueue = json_decode($buf, true);
if ($fileQueue != false && count($fileQueue['add']) > 0 || count($fileQueue['update']) > 0 || count($fileQueue['delete']) > 0) {
$data->actions[8]->visible = true;
} else {
$data->actions[9]->visible = true;
}
} else {
$data->actions[9]->visible = true;
}
} else {
$data->actions[9]->visible = true;
}
nun geht das Formular wieder auf.
Ok, im Debug stand dann trotz o.g. Filter
11.10.2022, 15:59:15 | Index | Skipping too big file... webfront/user/netatmo/2022/10/06/2022-10-06-08.29-84109e66.mp4. Size: 27,71 MB
Also habe ich mal den führenden / weggenommen, das scheint dann eher zu passen, aber
und tut sich nix,
die timer sind auch edle
und in den PHP-Informationen steht auch nichts (von diesem Modul)
Soll ich da irgendwo Debug einbauen und mal neu starten?
Rückfrage @paresy: gibt es hier irgend etwas neues? Ich habe es (mit der aktuellen Beta) vorhin nochmal probiert, das gleiche Bild.
Habe heute Mittag um 13:23 auch das Syncen erneut manuell ausgeführt und jetzt um 17:30 ist er immer noch dran. Bei mir kommt im Debug immer die Meldung:
11.10.2022, 17:24:18 | ReSync | Skipping. Upload has not completed yet
Hallo zusammen
Bei mir lief es auch erst wieder nach einem Neustart von Symcon.
bei mir läuft der Sync weiterhin miserabel. Seit 45 minuten läuft der Sync. So sieht mein Status aus, alles Dorpbox meldungen:
bin ich der einzige, bei dem das Modul permanent Meldungen schmeisst???
nö, bist nicht der einzige.
bei meiner produktiv-instanz funktioniert es auch nicht. nicht die gleiche Meldung, aber es wird nichts gesichert. bei der kleinen test-instanz ist das kein Problem, da funktioniert es.
nö, bei mir auch …
aber manchmal funktioniert es auch, trotz der Fehlermeldungen …
Hallo
Bei mir bleibt unreglmässig, so ca alle ein bis zwei Tage, der Dropbox-Sync-Vorgang hängen.
Ich muss in dann deaktivieren und erneut aktivieren.
Es scheint sich nicht immer um dieselbe Datei zu handeln, wo der Sync hängt.
Hier mal zwei dump-files mit Nachrichtenlimit, da wohl eh nur die hängende Datei relevant ist…
dump-dropbox-sync.txt (28,8 KB)
dump-dropbox-sync-2.txt (28,7 KB)
Der Speicherplatz der Dropbox ist bei weitem nicht voll, an dem liegt es nicht
Edit: Habe soeben festgestellt, dass die Protokollierung offenbar die ersten 100 Einträge aufzeichnet, nicht die letzten 100, welche eigentlich relvant wären… Werde daher nochmals ohne Limit aufzeichnen, vielleicht ist es dann trotzdem dieselbe Datei…
Bei mir das Gleiche, wird auch nicht mehr gesichert.
Manchmal geht es nach einer Deaktivierung und anschließender Aktivierung, aber auch nicht immer.
VG,
Doc
