Salzwedeler Militärgeschichte

Auf meiner Website zur Geschichte des Grenzregiments 24 beschäftige ich mich ja auch mit der Salzwedeler Militärgeschichte. Heute habe ich einen ersten Artikel über das preußische Kürassier-Regiment 7, das in Salzwedel zwischen 1718 und 1806 in Garnison lag veröffentlicht. Auf der Suche nach Informationen stiess ich auf ein weiteres von Google veröffentlichtes Buch zum Thema. Ich habe bereits auf das Buch zur Salzwedeler Stadtgeschichte von August Wilhelm Pohlmann aus dem Jahre 1811 aufmerksam gemacht (kann auf meiner Website herunter geladen werden). Am Samstag nun fand ich bei Google die „Geschichte des Sechsten königlich preußischen Kürassier-Regiments, gen. Kaiser von Russland“ geschrieben von Major E.A. Wilhelm Dijou von Monteton 1842.

Dieses nach der preußischen Niederlage gegen Napoleon aufgestellte Regiment, führte die Traditionen u.a. des Kürassier-Regiments 7 fort. In seinem Buch geht der Autor mehr oder weniger detailliert auf alle „Vorgänger“ seines Regiments ein. Im einzelnen waren das:

  • Kürassier-Regiment 2 (1806 v. Beeren)
  • Kürassier-Regiment 3 (1806 Leib-Kürassier-Regiment)
  • Kürassier-Regiment 6 (1806 v. Quitzow)
  • Kürassier-Regiment 7 (1806 v. Reitzenstein)
  • Kürassier-Regiment 10 (1806 Gens d’Armes)
  • Kürassier-Regiment 11 (1806 Leib-Karabinier-Regiment)

Die Reste dieser Regimenter bildeten nach der Niederlage von Auerstädt 1806 den Grundstock für die Aufstellung des Kürassier-Regiments 6.

Die Darstellung geht bis zur Veröffentlichung von Ranglisten und „Officiers-Abgang-Listen“ ab 1739. Ein interessantes Detail dabei ist z.B., dass Adolf v. Lützow – Kommandeur des Freikorps Lützow in den Befreiungskriegen – 1806 als Seconde-Lieutenant seinen Dienst im Kürassier-Regiment 7 (also dem „Salzwedeler“) versah und in der Schlacht von Jena und Auerstädt verwundet wurde.

ownCloud – Fehler in der Synchronisation

Schon in früheren Versionen meldete ownCloud ab und und „Fehler in der Sychronisation – lock-Datei kann nicht geschrieben werden“. Meistens trat das auf, wenn man den Synchronisationsvorgang abgebrochen hat aus welchen Gründen auch immer. In den Clientversionen 1.0.x fand ich irgendwann einen Workaround im Internet: im Homeverzeichnis des Users in das (versteckte) Verzeichnis .csync wechseln und dort die lock-Datei (heisst einfach lock, ohne Dateisuffix) löschen. Schon funktioniert die ganze Sache wieder.

Heute passierte mir dieselbe Sache nun mit dem neuen Client. Also altes Workaround, aber im angegebenen Verzeichnis existierte gar kein lock! Der Fehler nervte gewaltig, denn ausgerechnet auf dem Rechner zu Hause passierte die Sache (Entfernung zur Diskstation 80cm Luftlinie). Ich will jetzt nicht meinen gesamten Leidensweg beschreiben, den ich dann nach der alten try-and-error Philosophie gegangen bin (Neuinstallation des Servers und Clients usw.), denn die Lösung ist wesentlich einfacher:

Es existiert immer noch ein Verzeichnis, in das der Client sein lock schreiben will nur dieses Mal ist der Pfad:

/home/username/.local/share/data/ownCloud

Datei löschen (hat dann im Allgemeinen 0 Byte) und schon funktioniert die Sache wieder problemlos.

Im Zuge meiner Reparatur habe ich ja unter anderem auch den Server neu installiert (Datensicherung nicht vergessen!) und der Server läuft nunmehr unter Version 4.5.1. Interessanterweise gibt es dieses Mal nicht die Möglichkeit das Update direkt über die Paketverwaltung der Diskstation vorzunehmen. Wahrscheinlich erfolgt ein kompletter Neuaufbau der Datenbank … Auf dem Blog von Eric Gilian  werden die verschiedenen Methoden des Updates beschrieben und er begründet auch, warum ein Update auf dem bisherigen, bewährtem Weg nicht möglich ist.

ownCloud 4.5 und Client 1.1.1

In der Ankündigung zur aktuellen Version von ownCloud – also Version 4.5 – war ja immer die Rede von einer besseren Performance bei der Synchronisation wegen der nunmehr eingeführten Versionierung. Diese angekündigte Performancesteigerung konnte ich nicht feststellen …

Nach einigen Recherchen im Netz stiess ich auf die Aussage, dass mit der neuen Version des ownCloud-Servers ebenfalls ein neuer Client – Version 1.1 – released worden ist. Eine kurze Überprüfung auf meinem Rechner ergab, dass bei mir noch der Client in Version 1.05 werkelte. 

Da ich mit dem Update auf Kubuntu 12.10 die externen Quellen deaktiviert hatte – bzw. dass durch das Upgradeprogramm automatisch gemacht worden war – handelte es sich bei dem bei mir installierten Paket um das mit Kubuntu ausgelieferte. Hatte ich mich beim Upgrade noch gefreut, dass Kubuntu nunmehr den ownCloud-Client in den eigenen Repositories hält, musste ich nun wieder die externe Quelle freischalten:
als root ausführen:
echo ‚deb http://download.opensuse.org/repositories/isv:ownCloud:devel/xUbuntu_12.04/ /‘ >> /etc/apt/sources.list 
oder deb http://download.opensuse.org/repositories/isv:ownCloud:devel/xUbuntu_12.04/ 
den Softwarequellen in der Muon-Aktualisierungsverwaltung hinzufügen.
 
Ratsam ist es auch den Schlüssel herunterzuladen, um die Meldungen des Systems zu vermeiden, dass kein publicKey für die Anwendung vorhanden sei …Nach einem Update der Quellen bekommt man die Meldung über vorhandene Updates und nun wird der Client 1.1 tatsächlich installiert.
 
Etwas tiefergehende Recherchen im Netz sagen aus, dass die sync-Dateien verändert werden mussten, um die erforderlichen Informationen (Zeitstempel und Versions-ID) an die Datenbank übergeben zu können. Im Moment läuft die Synchronisation schon etwas mehr als 20 Minuten. Ich gehe davon aus, dass sie entsprechenden Änderungen bei der ersten Synchronisation etwas Zeit in Anspruch nehmen. Update folgt.
 
Update:
Die Synchronisation dauerte etwa 25 Minuten (auf jedem Rechner). Alle nachfolgenden Operationen liefen dann im Minutenbereich. Ziel erreicht – eine deutliche Performancesteigerung ist erkennbar.