[FTPSyncX] Thread zur App (private Cloud)

  • Antworten:142
Izzy
  • Forum-Beiträge: 6.929

18.12.2011, 14:15:25 via Website

@boerni: Falls es Dich tröstet, Du bist nicht der Erste. Obwohl es eigentlich so offensichtlich platziert ist, scheint es manchmal übersehen zu werden. Vielleicht sollten wir Christian vorschlagen, in der App einen passenden Menüpunkt einzubauen?

@TazZ: Ich hatte kürzlich einen anderen "Haker", an dem aber eher mein Netzwerk Schuld war ("keine Verbindung zum Server", weil der Timeout zu kurz war -- aber da ist in aktuellen Versionen der Default-Wert schon entsprechend angepasst). "Doppel-Syncs" hatte ich schon ewig nicht mehr.

Antworten
Martin S.
  • Forum-Beiträge: 69

20.12.2011, 00:44:44 via Website

Hm, ich habe hier eben das gleiche Problem, der ganze Haufen Dateien wird gesycnt obwohl gestern erst gesynct und sich nichts verändert hat...

Und ich habe auch noch zwei weitere Probleme:
- wenn sich Dateien auf beiden Seiten verändert haben wird einfach immer die neuere verwendet - das kann ziemlich unangenehm sein, wenn man nicht wirklich permanent synct, dann gehen einfach die Änderungen in einer der beiden Versionen verloren
- wenn der SMB Server nicht verfügbar ist beendet sich der Sync (manuell gestartet) einfach kommentarlos. Wollte die App schon deinstallieren, weil ich dachte es funktioniert nicht mehr. Hier wäre bei einem manuellen Sync wirklich eine notification wichtig, oder ein sync log oder irgendwas, woraus man ersehen kann ob der sync stattgefunden hat oder nicht. Ich glaube das wurde weiter oben schon mal erwähnt, wie schauts aus? :-)

Antworten
Izzy
  • Forum-Beiträge: 6.929

20.12.2011, 07:59:50 via Website

Lasst mich mal raten: Auf dem PC läuft Windows? Das liefert nämlich lt. Entwickler nicht immer einen zuverlässigen Timestamp, was die "Doppelsyncs" erklären würde.

Bei fehlgeschlagenem Sync (zumindest wenn der Server nicht oder nicht rechtzeitig antwortet) bekomme ich hier immer einen "Toast" (das sind diese kurzen Einblendungen von Nachrichten) mit der Meldung "Kann den Server nicht erreichen".

Und was die Sache mit "Auf beiden Seiten verändert" betrifft: Ja, das ist wohl korrekt. @Christian: Vielleicht solltest Du in einem solchen Fall auch einen entsprechenden Toast (plus Log-Eintrag) produzieren, und die Datei "unberührt" lassen -- sofern nicht eine der beiden Seiten explizit als "Master" deklariert wurde? Ggf. mit einer zusätzlichen Option für "force sync"?

Antworten
Martin S.
  • Forum-Beiträge: 69

20.12.2011, 09:24:05 via Website

Abweichende Timestamps bei Windows könnten das Problem sein, alle Sync Tools für Win (die was auf sich halten) haben eine Einstellung, eine Abweichung von ein paar Sekunden zu ignorieren, wahrscheinlich genau desweegen.

Und eine Log-Datei fände ich bei einem Sync-Tool auch sehr praktisch. Die Toasts sind schon etwas unauffällig (bei Sense zumindest).

— geändert am 20.12.2011, 09:24:22

Antworten
Gelöschter Account
  • Forum-Beiträge: 7.924

06.01.2012, 13:13:40 via App

Na die Kommentare häufen sich aber im Market, von wegen bereits gesyncte Dateien...

Problem haben also auch andere..

Desire HD > Note 2 LTE > Moto G > OnePlus One [Cyanogen OS | CM11S | root]

und jetzt noch ein Nexus 10 [Android 5 | root]
:D

Antworten
Izzy
  • Forum-Beiträge: 6.929

06.01.2012, 13:42:10 via Website

Ich kann es bis heute nicht nachvollziehen, bei mir läuft das sauber. Die Vermutung liegt nahe, dass diese Leute einfach kein Betriebssystem auf dem PC haben, welches die Timestamps der Dateien vernünftig zurückgibt -- sondern Windows benutzen, welches da oftmals ziemlich schlampt. Und das kann man der App kaum anlasten: Wenn sie falsche Informationen erhält, was soll sie da tun?

Btw: Die Information, dass es mit Windows zu tun haben könnte, kommt nicht von ungefähr -- die einzigen Anwender, die sich mit diesem Problem bislang an Christian gewendet haben (statt einfach nur irgendwo einen Kommentar zu hinterlassen), hatten diese Konstellation. Linux/Mac Benutzer hat sich damit noch keiner gemeldet.

Antworten
Gelöschter Account
  • Forum-Beiträge: 7.924

09.01.2012, 06:51:29 via Website

Zur neuen Version: Design ist auf jeden ganz schick! Kann man gut lesen!

Es gibt ja jetzt einen Logbericht!
Ist das dieser Timestamp?
09.01.2012 06:43:54 - File Shoud be downloaded (remote is newer (local:01.01.1980 00:00:00, remote:18.09.3810 16:10:00)):

tolle Zeiten^^

Desire HD > Note 2 LTE > Moto G > OnePlus One [Cyanogen OS | CM11S | root]

und jetzt noch ein Nexus 10 [Android 5 | root]
:D

Antworten
Gelöschter Account
  • Forum-Beiträge: 7.924

09.01.2012, 08:50:22 via App

Ach, Moment mal. Bei mir handelt es sich eigentlich um ein QNAP NAS mit Linux drauf, glaube ich. Sollte das da nicht besser klappen?

Desire HD > Note 2 LTE > Moto G > OnePlus One [Cyanogen OS | CM11S | root]

und jetzt noch ein Nexus 10 [Android 5 | root]
:D

Antworten
Izzy
  • Forum-Beiträge: 6.929

09.01.2012, 09:05:58 via Website

Was klappt denn "schlecht"? Dem von Dir geposteten Log-Eintrag entnehme ich, dass da eine Datei auf dem NAS war, die auf Deinem Androiden (noch) nicht existierte. Mehr nicht. Kein Problem, kein Indiz, dass etwas nicht richtig klappt. Da musst Du schon etwas konkreter werden :P

Antworten
Gelöschter Account
  • Forum-Beiträge: 7.924

09.01.2012, 15:09:25 via App

Die Datei befand aber sich auf beiden Seiten.
Izzy
Was klappt denn "schlecht"? Dem von Dir geposteten Log-Eintrag entnehme ich, dass da eine Datei auf dem NAS war, die auf Deinem Androiden (noch) nicht existierte. Mehr nicht. Kein Problem, kein Indiz, dass etwas nicht richtig klappt. Da musst Du schon etwas konkreter werden :P

Desire HD > Note 2 LTE > Moto G > OnePlus One [Cyanogen OS | CM11S | root]

und jetzt noch ein Nexus 10 [Android 5 | root]
:D

Antworten
Christian A.
  • Forum-Beiträge: 93

09.01.2012, 21:24:15 via Website

Ich kann ohne einen vollständigen Log auszug keine Fehleranalyse machen, aber hey stimmt ja bei dem Log gibt es eine option "Senden" bitte an meine Entwickler email weiterleiten dann schau ich mir das mal an :)

Antworten
Gelöschter Account
  • Forum-Beiträge: 7.924

10.01.2012, 08:21:10 via App

Kommt bei Gelegenheit. Vllt findest du ja den Fehler. Werde dann auch genau dazu schreiben was ich gemacht habe und wie die Konfiguration ist.
Danke
Christian A.
Ich kann ohne einen vollständigen Log auszug keine Fehleranalyse machen, aber hey stimmt ja bei dem Log gibt es eine option "Senden" bitte an meine Entwickler email weiterleiten dann schau ich mir das mal an :)

Desire HD > Note 2 LTE > Moto G > OnePlus One [Cyanogen OS | CM11S | root]

und jetzt noch ein Nexus 10 [Android 5 | root]
:D

Antworten
Harald B.
  • Forum-Beiträge: 12

10.01.2012, 14:23:43 via Website

Hallo zusammen,
@Martin S:
"Abweichende Timestamps bei Windows könnten das Problem sein, alle Sync Tools für Win (die was auf sich halten) haben eine Einstellung, eine Abweichung von ein paar Sekunden zu ignorieren, wahrscheinlich genau desweegen."
@Izzy:
Lasst mich mal raten: Auf dem PC läuft Windows? Das liefert nämlich lt. Entwickler nicht immer einen zuverlässigen Timestamp, was die "Doppelsyncs" erklären würde.

es handelt sich a) um eine Ungenauigkeit von ca. 2 sec.(FAT) b) um genau 1h - Sommer/Winterzeit/UTC-Zeit (NTFS) Quelle:http://de.wikipedia.org/wiki/Zeitstempel und http://www.heise.de/ct/hotline/Sommerzeit-und-NTFS-319486.html

@Christian A.Ich hatte mich gefreut endlich ein SyncTool gefunden zu haben, welches SMB/Samba-Freigaben unterstützt und nicht nur in die Cloud synct.
Nachdem ich die Free/Trail -Version einige Wochen dazu genutzt habe die Musikauswahl fürs Handy aktuell zu halten, habe ich mir heute Vormittag die Vollversion gekauft.
Doch jetzt erst habe ich festgestellt, das FTPSyncX weder die Zeitdifferenz der Dateisysteme berücksichtigt, noch das Dateidatum der Dateien erhält!
Das geht gar nicht! :angry:
Das ändern des Dateidatums ist ein "get no" bei einem Sync-Tool.

Als Folge des ersten/zweiten Syncs mit FTPSyncX sind meine sämtlichen Daten auf allen anderen Rechnern, dem Handy, dem Tablett, in der Cloud auch ersetzt worden, da ja (für andere Sync-Programme) ein neues Dateidatum/Erstelldatum/Änderungsdatum vorliegt. :what:

Ich habe gerade 2h damit verbracht, alle Daten zu löschen und rundum aus einem Backup wiederherzustellen.:angry:

Bitte, bitte ganz schnell nachbessern.

Gruß Harry aus Berlin

— geändert am 10.01.2012, 18:51:10

Antworten
Christian A.
  • Forum-Beiträge: 93

10.01.2012, 14:33:37 via Website

Der Zeitstempel wird NICHT verändert, in einer ganz alten Version war das mal so, aber in der aktuellen Version wird der Zeitstempel auf keiner Seite verändert.

Und natürlich berücksichtigt FTPSyncX Datei-Zeitstempel. Sonst würde ein Sync niemals funktionieren.
FTPSyncX geht wie folgt vor:
Testdatei lokal erstellen -> Zeit dieser Datei merken
Testdatei uploaden -> (Das Remotesystem wird dann einen eigenen Zeitstempel setzen)
Testdatei herunterladen -> Zeit dieser Datei mit der ersten Zeit vergleichen
=> Daraus ergibt sich der Zeitunterschied zwischen dem aktuellen Sync dieses Verzeichnisses
Die Zeitunterschiede kommen dann in die Datenbank inkl Dateipfade das heisst sollte das Remotesystem ein anderes Datum zurück liefern wie es beim ersten mal getan hat so sieht FTPSyncX diese Datei als "geändert" an.

Ich kann natürlich hier nicht den ganzen Programmcode aufschreiben oder mit einer Beschreibung wiedergeben, allerdings weis ich sehr genau, dass der Zeitstempel von den Dateien nicht verändert wird.

Ich weis nicht ob du vielleicht meinst das beim "erstellen" der Datei nicht der 100%ige gleiche Zeitstempel wie auf der original Datei liegt.
(Z.B. wenn ich eine Datei hochladen, dass die hochgeladene Datei den selben Zeitstempel erhält wie den den sie auf der lokalen Seite hat)
Dies ist aber leider Technisch nicht möglich. Ich dachte auch erst ich werde diesen Weg gehen aber es hat mir bei dem Servertyp "FTP / FTPS" einen Strich durch die Rechnung gemacht, da das Modifizieren eines Timestamps bei FTP bzw. FTPS-Server nicht in jeder Software implementiert ist zusätzlich heisst es offiziel das der Modify befehl für Zeitstempel kein offizieler FTP Befehl ist und daher habe ich diesen Weg aufgegeben.

— geändert am 10.01.2012, 14:34:00

Antworten
Christian A.
  • Forum-Beiträge: 93

10.01.2012, 14:37:31 via Website

Harald B.

@Christian A.Ich hatte mich gefreut endlich ein SyncTool gefunden zu haben, welches SMB/Samba-Freigaben unterstützt und nicht nur in die Cloud synct.
Nachdem ich die Free/Trail -Version einige Wochen dazu genutzt habe die Musikauswahl fürs Handy aktuell zu halten, habe ich mir heute Vormittag die Vollversion gekauft.
Doch jetzt erst habe ich festgestellt, das FTPSyncX weder die Zeitdifferenz der Dateisysteme berücksichtigt, noch das Dateidatum der Dateien erhält!
Das geht gar nicht! :angry:
Das ändern des Dateidatums ist ein "get no" bei einem Sync-Tool.

Nur so eine Frage, wieso auf einmal jetzt? Die Syncprozedur hat sich in den letzten Wochen nicht ein bischen verändert. Ihre Probleme müssten dann auch schon in ihrer Testphase entstanden sein.

Grüsse,
Christian

Antworten
Harald B.
  • Forum-Beiträge: 12

10.01.2012, 14:56:45 via Website

Danke für die schnelle Antwort,
In der Testphase, bei der ich die (Musik-)Dateien einfach in einen Ordner meines Servers geschmissen habe und sie, durch die App, auf das Handy habe "kopieren" lassen, habe ich das Dateidatum nicht im Auge gehabt. Die Dateien waren da und gut wars.
Ich werde das synchronisieren nochmals testen. - Als erstes ist es mir bei einem Sync, mit einer Datei aufgefallen, die den besagten Zeitunterschied von 1h aufgewiesen hat.
....was ist bei mir schief-gelaufen? Ich melde mich nach der Testphase. (kann aber dauern die Kinder kommen gerade aus der Schule)

Gruß Harry

Antworten
Christian A.
  • Forum-Beiträge: 93

10.01.2012, 16:00:40 via Website

Wie gesagt besagter Zeitunterschied ist ganz normal
Datei existiert nicht auf Smartphone
Datei auf PC 16:00 wird vom Betriebssystem angezeigt
Aktuelle Zeit 20:05
Datei download
Datei auf smartphone 20:05
Datei auf remote bleibt bei 16:00

Das ist auch entsprechend der Problembeschreibung meines vorletzten Posts nicht anders möglich.

— geändert am 10.01.2012, 16:01:02

Antworten
Izzy
  • Forum-Beiträge: 6.929

10.01.2012, 16:35:14 via Website

Christian A.
Datei auf PC 16:00 wird vom Betriebssystem angezeigt
Aktuelle Zeit 20:05
Datei download
Datei auf smartphone 20:05
Datei auf remote bleibt bei 16:00

Das ist aber der Part, wo es vom "Standard" abweicht (da würden die Timestamps identisch sein, sobald der Vorgang abgeschlossen ist). Warum das Anpassen eines Timestamps lokal nicht möglich ist, habe ich nie kapiert (als nicht-AndroidProgrammierer muss ich das wohl so hinnehmen -- obwohl es mich wundern würde, wenn das zugrundeliegende Linux kein "touch" könnte). Remote habe ich das kapiert: Da fehlt der entsprechende Standard z.B. im FTP-Protokoll. Vielleicht kannst Du das nochmal kurz erklären, um die letzten Missverständnisse auszuräumen?

@Alle: Kurz zum Verständnis. FTPSyncX merkt sich (in aktuellen Versionen) die jeweiligen Timestamps in einer internen Datenbank. Im obigen Beispiel weiß die App also, dass beim letzten Sync lokal "20:05" und remote "16:00" aktuell waren -- vergleicht also beim nächsten Sync die lokale Datei mit "20:05", und remote mit "16:00" (vereinfacht gesagt). Solange also niemand für die gleiche Verbindung (also die gleichen beiden Geräte & Verzeichnisse in dieser Kombination) mit einer anderen App synchronisiert, oder einen "Kreisverkehr" aufbaut, sollte das keine Probleme verursachen.

Antworten
Christian A.
  • Forum-Beiträge: 93

10.01.2012, 16:38:48 via Website

Izzy bringts auf den Punkt. Aber genau da ist der knackpunkt. Klar android bietet mir die möglichkeit den Timestamp zu setzen. Aber wer geht davon aus das dieser Timestmap korrekt ist? Windows liefert ja wie oben schon geschrieben immer mal andere Timestamps womit dann andere Sync programme auch probleme haben. Anderer seits müsste ich mal nachschauen ob ich nich sogar doch die lokalen Timestamps setze (kenne den code noch nicht auswendig :P)

Antworten
Izzy
  • Forum-Beiträge: 6.929

10.01.2012, 16:47:38 via Website

Falls noch nicht der Fall, solltest Du das zumindest lokal noch nachholen. Wenn Du mich fragst, auch remote, wo es geht. Immer soweit wie irgend möglich bei den "Standards" bleiben. Und die sehen nun einmal beim Sync vor, dass anschließend die jeweiligen "Dateipaare" auf beiden Seiten den gleichen Timestamp tragen. Wo das nicht geht, geht es halt nicht (und um der Einheitlichkeit / Einfachheit halber kannst Du ja die Timestamps dennoch für alle verwendeten Protokolle in der Datenbank speichern -- dann funzt das auch noch, wenn jemand mal im Nachhinein das Protokoll wechselt, z.B. von FTP zu SCP oder umgekehrt).

Antworten
Harald B.
  • Forum-Beiträge: 12

10.01.2012, 16:55:45 via Website

Bisher hat das bei meinen anderen Sync-Programmen so funktioniert.
Ursprungs-und Ziel-Dateidatum sind identisch.
Ob die Datei nun vorhanden war oder erst erstellt wurde.

Gruß Harry

Antworten
Harald B.
  • Forum-Beiträge: 12

10.01.2012, 17:47:36 via Website

@Christian A.
ich habe versucht das Problem zu verifizieren, einen neuen Ordner (auf dem Server) erstellt, eine alte Datei hinein, am Handy Sync-konfiguriert, Sync-gestartet, Dateien verglichen.
Was soll ich sagen? die Datei wurde am Zielort (Handy) neu erstellt und das Dateidatum ist erhalten geblieben! Wie geht das denn.
Jedoch wurde aus 21:56:36 (Orginal) auf dem Handy 21:55:00. (Die Zeiten habe ich am Server ausgelesen, auf dem Handy läuft die "Samba Filesharing-App")
Auf dem Handy wird mir die Zeit als 22:55:00 (entsprechend 22:56:36) angezeigt.
Dieser SMB-Sync war vom Serverspeicher auf das Handy.

:( Ich probiere das jetzt noch mal andersherum.

BTW:
zum Thema "FTP" taucht in meinen Recherchen immer mal wieder ein MLSD-Befehl auf. "....ermittelt die Dateiliste über den MLSD-Befehl. Dieser gibt die
Zeitstempel inklusive Sekunden zurück. Der normale LIST-Befehl kennt keine Sekunden."

Antworten
Christian A.
  • Forum-Beiträge: 93

10.01.2012, 17:50:10 via Website

Harald B.
Bisher hat das bei meinen anderen Sync-Programmen so funktioniert.
Ursprungs-und Ziel-Dateidatum sind identisch.
Ob die Datei nun vorhanden war oder erst erstellt wurde.

Gruß Harry

Wie gesagt, es kann gut sein das SMB dieses feature mit sich bringt (SFTP SSH macht das auch) aber FTP und FTPS nicht.

Nachholen ist nich einfach so gesagt, ich muss schauen ob das dann auch noch mit meinem restlichen code im einklang bleibt und es nicht durch diese änderung es sich verschlimmbessert und dann wirklich doppel syncx innerhalb meiner app passieren.

Antworten
Harald B.
  • Forum-Beiträge: 12

10.01.2012, 17:55:17 via Website

@Christian A.

SO! DA ist ER.
Beim SMB-sync vom Handy auf das Server-Verzeichniss geht beim (neu?)erstellen der Datei das Datum verloren!

Gruß Harry

Antworten
Christian A.
  • Forum-Beiträge: 93

10.01.2012, 19:42:48 via Website

So habe nun die App kurz angepasst und ein update hochgeladen, sollte in den nächsten Minuten / Stunden wie lang auch immer der market braucht verfügbar sein.
SFTP + SMB timestamps werden nun beim upload gesetzt, bei FTP und FTPS ist dies leider nicht möglich
Lokal wurden schon immer die Timestamps von der Remotedatei gesetzt.

Grüsse,
Christian

Antworten
Harald B.
  • Forum-Beiträge: 12

10.01.2012, 20:34:59 via Website

@Christian A.
Bitte, bitte ganz schnell nachbessern.

Danke, Danke super schnell nachgebessert:grin:

Gruß Harry aus Berlin

Antworten
Gelöschter Account
  • Forum-Beiträge: 7.924

10.01.2012, 22:22:31 via App

Jo läuft, keine unnötigen Syncs mehr per SMB, DANKE

Desire HD > Note 2 LTE > Moto G > OnePlus One [Cyanogen OS | CM11S | root]

und jetzt noch ein Nexus 10 [Android 5 | root]
:D

Antworten
Christian A.
  • Forum-Beiträge: 93

10.01.2012, 23:32:22 via Website

Vergesst nicht die app zu bewerten *grins* :)

Antworten
Harald B.
  • Forum-Beiträge: 12

10.01.2012, 23:44:30 via Website

Next! Problem!

Ich synce einen der Ordner, (den ich heute gegen 12:00Uhr auf dem Handy und dem Server wiederhergestellt habe (siehe Threat von 10.01.2012 14:23:43) er enthält 1,42 GB (1.530.679.296 Bytes), 2390 Dateien in 238 Ordnern.
FTPSyncX stellt nach 4min Recherche fest das alle (?) Dateien "hoch-geladen" werden müssen.
(OK - warum auch immer, eigentlich sollten die Dateien seit 12:00 Uhr identisch sein)

Transfer braucht seine Zeit, also das Handy auf die Dockingstation zum laden, der Dock-Screen kommt in den Vordergrund.
Ich möchte noch ein kurzer Blick auf die App und den Fortschritt werfen (um später die Zeit abschätzen zu können), schließe den Dock-Screen und bekomme nur noch die App zu sehen.
Das Fenster "Bitte warten..." mit der Anzeige des Fortschritts ist verschwunden (?)
Letzter Sync:2012-01-10 21:10 steht dort, das ist 15min her. (?)
Es läuft jedoch noch ein FTPSyncX-Prozess der sich dann plötzlich von selbst beendet.(?)
Die App ist nach dem Verlassen des Task-Managers noch da.
Ein erneuter Start des Verzeichnis-Syncs (wieder 4min Recherche), App synct dann weiter. ? Es sind jetzt weniger Dateien zu syncen.
Ich nehme das Handy aus dem Dock, das gleiche Spiel wie eben Fenster weg, sync abgebrochen. (!)
Nochmal, erneuter Start des Verzeichnis-Syncs (wieder 4min Recherche) sync startet wieder.
Ich drehe das Handy ins Querformat, ....wieder bricht der sync ab. (!)
Beim langen drücken des Verzeichniseintrags und dem erneuten Versuch die Synchronisation zu starten kommt die Meldung "Sync Abgebrochen, dieses Verzeichnis wird gerade synchronisiert" bei einem erneuten Versuch ein paar Sekunden später, wird das Verzeichnis wieder "4min"untersucht (Der laufende Sync ist anscheinend wieder gestorben).

Nach dem 5. Anlauf nun nach 4min Wartezeit die Meldung "Verzeichnis ist synchronisiert"

Sag was...Christian:(

Harry

p.s. Sorry for this bad news kurz nachdem du uns zum voten aufgefordert hast.:*)

Antworten
Christian A.
  • Forum-Beiträge: 93

10.01.2012, 23:52:32 via Website

Also das das dialogfenster beim drehen des screens verschwindet werde ich noch unterbinden, beim verlassen der app werde ich schauen, ob ich das ordentlich hinbekomme, dass der dialog bleibt (oder halt neu erstellt wird) weis nur noch nicht wie ich das hinbekomme.
Ansich kann ich aber sagen der sync wird dann nicht abgebrochen, er läuft in jedem fall im hintergrund weiter, daher auch der prozess der sich urplötzlich beendet ( dann ist der sync fertig ). Als indikator hast du auch korrekter weise festgestellt das nun ein eintrag steht womit man den sync status zurück setzt (Dieser punkt ist aber mit vorsicht zu geniessen) ich locke nicht ohne grund ein verzeichniss wenn er gerade am syncen ist. welche genauen probleme dadurch entstehen einen sync 2x am laufen zu haben ( 2x das gleiche verzeichnis) kann ich nicht sagen, aber es wird definitiv nebenwirkungen haben :P
Mir ist das bisher einmal passiert, dass ein Sync eigentlich schneller fertig war als ich geschätzt habe und tatsächlich ein weiterer klick hat dann genau zu diesem ergebniss gebracht das er wieder synct aber weniger dateien. da ich den fehler bisher nicht wieder reproduzieren konnte ging ich von einem einmaligen problem aus. (Dachte da ansowas wie "android killt prozess weil es mehr speicher braucht").
Werde schauen ob ich den Fehler reproduzieren kann.

und nun gute nacht :P

— geändert am 10.01.2012, 23:53:06

Antworten
Harald B.
  • Forum-Beiträge: 12

10.01.2012, 23:53:44 via Website

Bei einem Vergleich/Sync der Verzeichnisse bestätigt mir der Totalcomander, das beide 'Verzeichnisse identisch sind!:grin:

Jedoch fällt auf, das keine Datei mehr eine Uhrzeit mit Sekunden Angaben enthält! Alle Sekunden sind stehen auf ":00"

Harry

Antworten
Christian A.
  • Forum-Beiträge: 93

10.01.2012, 23:57:19 via Website

Grml.... ja ;) ist so beabsichtigt. mein tool geht aif minuten gleich. sekunden gab tändig probleme und führte zu doppel syncs... weil server mal wieder ne sekunde zu langsam o. zu schnell ist.

Antworten
Harald B.
  • Forum-Beiträge: 12

11.01.2012, 00:55:18 via Website

Ja, ja, ja - es ist viel zu spät früh ich weiß.
Aber ich hab da noch, was zuende bringen müssen......

Im Log steht: 11.01.2012 00:09:32 - File Shoud be uploaded (local is newer
(local:10.09.2009 23:36:00, remote:13.05.2007 11:21:00)): /Leitfaden.pdf

Aus der Datei am Handy lese ich aus; (nach dem Sync)
Erstellt: Donnerstag, 10. September 2009, 00:00:00
Geändert am: Donnerstag, 10. September 2009, 22:36:00
Letzter Zugriff: Donnerstag, 10. September 2009, 00:00:00

Aus der Datei am Server lese ich aus; (nach dem Sync)
Erstellt: Mittwoch, 13. April 2011, 18:01:53
Geändert am: Donnerstag, 10. September 2009, 22:36:00
Letzter Zugriff: Heute, 11. Januar 2012, 00:28:35

Aus dem Backup vom 2009-12-07_2010 (ww vor dem Sync)
Erstellt: Samstag, 19. September 2009, 21:00:52
Geändert am: Donnerstag, 10. September 2009, 22:36:15
Letzter Zugriff: Heute, 11. Januar 2012, 00:27:12

Wo in aller Welt kommt "remote:13.05.2007 11:21:00" her? ....und wird zum Vergleich herangezogen?
Das liegt eindeutig vor dem Erstelldatum dieser PDF-Datei !

Harry ????:rolleyes:

Antworten
Christian A.
  • Forum-Beiträge: 93

11.01.2012, 07:13:16 via App

keine ahnung aber wie du bemerkt hast ich nutze nur das changedate das ist das einzigste darum was ich auslehe und setzte. alles andere macht android o. server

Antworten
Harald B.
  • Forum-Beiträge: 12

11.01.2012, 09:07:27 via Website

keine Ahnung ist aber nicht gut!
Laut deinem Log benutzt Du ein Datum (13.05.2007 11:21:00) welches nicht das "changedate" ist!

Gruß Harry

Antworten
Christian A.
  • Forum-Beiträge: 93

11.01.2012, 15:16:13 via Website

Hab mir nochmal den Eintrag durchgelesen und folgendes festgestellt:

Aus der Datei am Handy lese ich aus; (nach dem Sync)
Erstellt: Mittwoch, 13. April 2011, 18:01:53

Da ist an ihrem Server etwas falsch, FTPSyncX erstellt die Datei einfach, das Erstellungsdatum wird definitiv vom Server erstellt.
Wenn gesynct worden ist muss das Erstellungsdatum auf dem aktuellen Datum liegen und nicht ein 3/4 Jahr in der Vergangenheit.

Antworten
Harald B.
  • Forum-Beiträge: 12

11.01.2012, 22:28:49 via Website

Ich glaube erst einmal nicht das an meinem Server etwas falsch seien könnte! :grin:
Ersteinmal glaube ich, das ein seit 6 Jahren laufendes System, welches in dieser Zeit keine solchen Probleme hatte, einwandfrei funktioniert.
Dann glaube ich, das ein "Windows Home Server", als ein Ableger des Windows Server 2008, Dateireplikation und Netzwerkkommunikation auf einer Ebene beherrscht, die aufgrund der Einsatzbereiche immer noch als eine Maßgabe angesehen werden muss.
Deshalb glaube ich erst einmal, das ein neues Netzwerktool/App auf einem Linux/Android - System/Handy einen Fehler bei der SMB-Protokoll Behandlung hat.

Die Log sagt z.B.:
11.01.2012 00:09:39 - File Shoud be uploaded (local is newer (local:24.03.2011 16:51:00, remote:05.06.2010 23:50:00)): /Schulordnung auswahl.pdf
Der Es-Datei Explorer sagt: 24.03.2011 16:51:36 (auch "remote") ein anderes Datum als FTPSyncX


Wie bitte kommen beide Programme zu so unterschiedlichen Aussagen?
Die Angabe des Es-Datei Explorer deckt sich mit dem am Server ausgelesenen Datum.

Ich habe deshalb erst einmal, Zweifel an der Richtigkeit des von FTPSyncX ausgelesenen Datums.

Ich wollte gerade eben noch ein weiteres Log mit einer anderen(neuen) Datei erstellen, musste dabei jedoch feststellen das,
a) FTPSyncX in dem heute früh (11.01.2012 00:09:XX) fertig synchronisierten Verzeichnis nicht nur eine sondern gleich 195 neue/geänderte Dateien entdeckte. Wie das?
b) Als ich die Log Datei speichern wurde sie als ".log" zum speichern angeboten. und
c) FTPSyncX, beim Versuch zu speichern vollends abstürzte. und
d) nach einem Neustart, mich erneut mit den AGBs bekanntmachte und die Serverliste und damit auch die konfigurierten Verzeichnisse verschwunden waren.

GRRR(uß)
Harry

— geändert am 11.01.2012, 22:32:51

Antworten
Christian A.
  • Forum-Beiträge: 93

11.01.2012, 23:11:44 via Website

Das die AGB's neu angezeigt werden, kann nur dann passieren, wenn FTPSyncX in der Datenbank einen Wert innerhalb eines Feldes nicht findet. FTPSyncX löscht dieses Feld (oder übschreibt es) niemals, dieser Befehl ist im quellcode nicht enthalten und kann somit nie ausgeführt werden. Es existiert nur ein Befehl "setze wert auf einen festen wert" und zwar den Wert, dass dieser Dialog nicht mehr angezeigt wird, weiterin kann die Datenbank ansich nicht durch FTPSyncX zerstört werden. Sollte dies dennoch der Fall sein dann haben Sie gerade einen Bug in ihrem Android-Betriebssystem festgestellt.

Nochmals zur Problematik mit dem Zeitunterschied. Es kann vorkommen, dass das Änderungsdatum eine gewisse Zeitdifferenz zu der, die eine andere App anzeigt, aufweist. Grund hierfür ist, dass ich den Zeitstempel - der gefundenen Zeitdifferenz zwischen Smartphone und Server anzeige. Das heisst wenn bei der Zeitdifferenz berechnung ein wert von minus einer Stunde herauskommt, und im Windows Explorer 16:00 angezeigt wird dann würd dann merkt FTPSyncX das die gegenstelle um eine Stunde in der Zukunft liegt und zieht somit diese Stunde von 16:00 auf 15:00 ab und das wird dann angezeigt.
Abgesehen davon wie ich in der letzten Mitteilung schon geschrieben habe ist es für FTPSyncX unmöglich das Erstellungsdatum anzupassen, dieser Befehl ist im Programmcode nicht implementiert, das einzigste was nun neu implementiert ist ist das Änderungsdatum.
Bei einem Upload jeglicher Art (FTP, FTPS, SFTP oder SMB) wird zuerst eine Datei originaldateiname.originalendung.FTPSyncX erstellt. Da diese datei noch nicht existiert (soltle sie existieren wird sie vorher gelöscht) so MUSS diese Datei das aktuelle Datum beinhalten, da diese Funktion so vom Betriebssystem/Serverdienst implementiert ist. Sofern der Upload erfolgreich ist wird die alter original datei gelöscht und die .FTPSyncX datei in die original datei umbenannt (Schutz das bei einem Fehlerhaften upload die alte Datei nicht kaputt geht (z.,B. bei Verbindungsverlust)).
Ich kann hier nur wiederholen, dass ein Erstellungsdatum von einem 3/4 Jahr in der Vergangenheit "nach" einer Synchronisation nicht möglich ist.

Aber damit solche Diskussionen nicht weiter auftreten werde ich wohl die Zeitangaben aus dem Log entfernen, da dies anscheinend mehr verwirrung als nutzen schafft.
Ich kann versichern das die "Zeit"-Überprüfung korrekt verläuft und das nun in der Version 1.1.6.3 bei den Servertypen SFTP und SMB (Samba) das Änderungsdatum beim upload gesetzt wird so wie es hier gewünscht worden ist.

Antworten
Christian A.
  • Forum-Beiträge: 93

16.01.2012, 23:27:44 via Website

Hallo an Alle,

Izzy hat den nagel getroffen, ich finde ich möchte schon gerne allen Usern ein möglichst grosses Spektrum an Diensten anbieten, allerdings finde ich die "Sicherheits"-Frage durchaus berechtigt.
Aktuell schwebt mir vor das bei Auswahl von DropBox ein Dialog aufgeht der den Benutzer warnt das er einen Öffentlichen Cloud-Dienst damit nutzen würde und dies für sensible Daten nicht gerade Sinnvoll ist.

Wie seht ihr das ?
Dropbox einfach mit reinnehmen oder Ggf. eine weitere App hinzufügen die Dropbox beinhaltet ? Oder ggf. habt Ihr ja noch weitere Vorschläge (Wie Izzy schon erwähnte ein Plugin ist leider bei der derzeitigen Programmierung nicht mehr möglich).

Grüsse,
Christian

Antworten
Gelöschter Account
  • Forum-Beiträge: 3

19.01.2012, 22:58:41 via App

App im Appcenter gekauft, leider funktioniert die Lizenzierung nicht. Fragt immer, ob er es neu versuchen soll oder abbrechen...

Antworten
Christian A.
  • Forum-Beiträge: 93

19.01.2012, 23:01:45 via Website

An alle,

Ich werde bis zum Wochenende (Vielleicht auch erst am Sonntagabend) ein Update hochladen welches eine neue Debug-Funktion beinhaltet, damit können dann Debuginformation aufgezeichnet und mir zugesendet werden, dadurch kann ich dann besser feststellen wo genau das Problem liegt. Es ist für einen Entwickler immer sehr schwer Ferndiagnosen abzugeben.

Wegen den Lizenzproblemen werde ich mich einmal mit Androidpit auseinander setzen.
Ich versuche das Problem so schnell wie möglich zu beheben.
Merkwürdig ist auch das dass Problem nicht bei allen auftritt, nur bei manchen.

Grüsse,
Christian

Antworten
Gelöschter Account
  • Forum-Beiträge: 3

19.01.2012, 23:12:36 via App

Was mache ich jetzt? Warten? Zurückgeben?

LG Bertram

Antworten
Izzy
  • Forum-Beiträge: 6.929

19.01.2012, 23:15:27 via Website

Beim Google-License-Check trat ein derartiges Problem auch bei verschiedenen Apps auf. In diesen Fällen half eine Erhöhung des Timeouts sowie der Anzahl der Retries, das Problem zu lösen. Für temporäre Server-/Netzwerk-Probleme könntest Du ja auch einbauen, dass bei einem Fehlschlag selbiger für einen gewissen Zeitraum "ignoriert" wird (z.B. für 3-5 Tage); diesen Zähler natürlich dann ggf. bei Erfolg wieder zurücksetzen ;)

@Bertram: Warten. Der Christian hat doch gerade ein Update angekündigt. Gib ihm eine Chance: In der Regel kriegt er Probleme recht schnell beseitigt. Als Langzeit-Nutzer spreche ich da aus Erfahrung :P

— geändert am 19.01.2012, 23:17:34

Antworten
Christian A.
  • Forum-Beiträge: 93

19.01.2012, 23:16:47 via Website

Ich habe gerade Androidpit eine Nachricht hinterlassen.
Es bleibt ihre Entscheidung ob Sie die Applikation zurückgeben, ich kann nur vergewissern das ich das Problem aufjedenfall Lösen werde.
Unabhängig davon ob es nun meine eigene App ist oder nicht würde ich warten.

Grüsse,
Christian

Antworten
Gelöschter Account
  • Forum-Beiträge: 7.924

19.01.2012, 23:39:28 via Website

als User der App kann ich dazu sagen: Das Lizenzproblemen tritt zwar bei mir auch auf, jedoch kann ich nach erneutem Starten die App problemlos nutzen. Sie funktioniert.

Alte Probleme (s.h. Market-Kommentare) treten bei mir nach dem neusten Update nicht mehr auf!

*App ist klasse -- jeden Cent Wert*

Desire HD > Note 2 LTE > Moto G > OnePlus One [Cyanogen OS | CM11S | root]

und jetzt noch ein Nexus 10 [Android 5 | root]
:D

Antworten
Gelöschter Account
  • Forum-Beiträge: 3

20.01.2012, 11:16:26 via Website

OK, dann werde ich warten:)

Antworten