Ich habe gestern von meinem Nexus 4 eine KeePass-Datei mit DS file auf mein Synology-NAS hochgeladen und anschließend von meinem Nexus 7 aus mit DS file wieder heruntergeladen. Beim Versuch, diese zu öffnen, hat sich KeePass über eine fehlerhafte Datei beschwert. Ein Vergleich der beiden Dateien hat gezeigt, daß die über das NAS kopierte Datei nur 49,00 kb hat, während die lokale Datei eine Größe von 49,01 kb aufweist.

In einem Versuch mit einer Textdatei ließ sich das Verhalten reproduzieren: die auf dem Nexus 4 noch 189 Byte große Datei ist nach dem Hochladen nur noch 180 Byte groß, es fehlen einige Zeichen am Ende. Auch bei einem testweisen Upload über das Nexus 7 wurden Dateien beschädigt.

Nachdem klar war, daß wohl tatsächlich ein Fehler besteht, habe ich gestern Abend direkt ein Support-Ticket mit folgendem Wortlauf bei Synology eröffnet:

Problem Explanation:

Hi,

I have the problem, that since the last update DS file seem to corrupt files when uploading to the DiskStation.

The Android device is a Google Nexus 4 running Android 4.4.3

I noticed the error when uploading a KeePass file to the DiskStation, downloaded it to a Nexus 7 (also running Android 4.4.3) and could’t open the file with KeePass complaining the file being corrupt.

I also couldn’t open the uploaded file when downloading it back to the Nexus 4 as KeePass also claimed the file being corrupt.

Problem Reproduce Steps:

I choose a textfile with some URLs (189 bytes on mobile phone), upload it to the DiskStation and the file size changes to 180 bytes. The last characters of the file are missing.

Sicherheitshalber habe ich parallel dazu auch noch eine Mail an Carsten Knobloch, den Betreiber von stadt-bremerhaven.de verschickt, der das Problem verifizieren konnte. Während er wenige Stunden nach seinem Blogeintrag bereits eine E-Mail von Synology mit dem Hinweis, daß die App vorübergehend aus dem PlayStore genommen wurde, erhielt warte ich 24 Stunden später noch immer auf eine Reaktion vom Support … Aber bestimmt erklären die mir irgendwann, daß das Problem doch längst behoben sei …

Wirft man einen Blick in die Verbrauchsanzeige eines Smartphones, so fällt auf, daß neben dem Display vor allem das ständige Offenhalten der Daten-Verbindung am Akku nagt. Sofern man damit leben kann, daß nicht jede Nachricht sekundengenau aufschlägt, lässt sich genau an dieser Stelle ansetzen und die mobile Datennutzung zeitlich steuern was die Standby-Zeiten deutlich verbessert.

Hierzu können z.B. in Llama, den “Location Profiles für Android” drei Regeln angelegt werden, welche die automatische Steuerung übernehmen:

Mobiles Netz automatisch aus

• Wenn sich der Bildschirm ausschaltet

• Wenn Mobildaten aktiviert sind

• um 2 Minuten verzögern und dann Datennetzmodus deaktivieren

Diese Regel sorgt dafür, daß bei ausgeschaltetem Display und eingeschalteten Mobildaten diese nach 2 Minuten automatisch deaktiviert werden.

Mobiles Netz automatisch ein

• Wenn sich der Bildschirm ausschaltet

• Wenn Mobildaten deaktiviert sind

• um 13 Minuten verzögern und dann Datennetzmodus aktivieren

Diese Regel ist das Gegenstück zu “Mobiles Netz automatisch ein” und sorgt dafür, daß bei ausgeschaltetem Display und Mobildaten diese nach 13 Minuten aktiviert werden.

Mobiles Netz mit Bildschirm ein

• Wenn sich der Bildschirm einschaltet

• Wenn Mobildaten deaktiviert sind

• Datennetzmodus aktivieren

Die letzte Regel dient dazu im Bedarfsfall zusammen mit dem Bildschirm auch die Mobildaten einzuschalten.

Natürlich sind der künstlerischen Freiheit beim Gestalten der Regeln keine Grenzen gesetzt. So kann zum Beispiel über eine Llama-Variable die automatische Steuerung ortsbezogen ein- oder ausgeschaltet oder auch eine Ruhezeit definiert werden, in der die Datenverbindung überhaupt nicht aktiviert wird.

Interessant, was der Auswahlschirm zum “Exchange 2013 Bereitstellungs Assistent” so an Auswahloptionen bietet:

“Exchange 5.105,40 cm”? Klingt interessant!

Das Java Runtime Environment (JRE) hat sich in den letzten Jahren einen unrühmlichen Ruf als potentielles Einfallstor für Schädlinge aller Art ins System erworben, so daß - sofern nicht unbedingt benötigt - das JRE entweder erst gar nicht installiert oder zumindest im Browser deaktiviert werden sollte.

Um so ärgerlicher ist, wenn ohne entsprechende Information oder Abfrage eine veraltete JRE-Version über Drittsoftware auf den Rechner gelangt:

Im aktuellen Fall ist dies eine Adobe Photoshop CS5-Installation, in deren Verlauf im Ordner “C:\ProgramData\Adobe\CS5\jre” ein zum Installationszeitpunkt hoffnungslos veraltetes JRE 6.0.18 aus dem März 2010 abgelegt wird und die auch nach Einspielen aller für Photoshop CS5 erhältlichen Patches den ursprünglichen Versionsstand beibehält.

Umso ärgerlicher ist, daß das JRE weder in der Systemsteuerung angezeigt noch über diese aktualisiert oder deinstalliert werden kann, zumal fraglich ist, ob Photoshop unter Windows überhaupt ein JRE benötigt: laut einer kurzen Recherche mittels Google scheint dieses ausschließlich für die Flash-Kompontente der Creative Suite vorausgesetzt zu werden.

Und tatsächlich: nach Zippen und anschließendem Löschen des Ordners scheint Photoshop weiterhin problemos zu funktionieren, so daß zumindest auf diese Sicherheitslücke getrost verzichtet werden kann.

Der Video Disk Recorder (VDR) ist eine feine Sache: einfach eine digitale TV-Karte (entweder C/S oder T) in einen antiquierten PC einbauen und schon steht für wenig Geld ein vollwertiger digitaler Videorekorder zur Verfügung.

Neben speziellen VDR-Distributionen wie z.B. dem c’tVDR eignet sich fast jede Linux-Distribution als Basis. Dieser Artikel beschäftigt sich mit der Installation eines “normalen” SD-VDR auf Basis von Debian Wheezy.

Als Blaupause für die Basisinstallation dienten die Artikel von Tobias Grimm und Martin Selbald, wobei einige Hard- und Software-spezifische Besonderheiten eigene Lösungen benötigten. Die erste (nicht veröffentlichte) Fassung dieses Beitrags basierte auf der Installation eines No-Name-Rechners, die aktuelle Fassung wurde für die Installation auf einen DELL Precision T3400 überarbeitet. Eine wesentliche Änderung hierbei war der Umstieg von NVRAM-Wakeup auf ACPI Wakeup.

Weiterlesen