Dateisuche in Windows für Unerschrockene (4.6.2013)
Für meine Buchhaltung digitalisiere ich alle Belege, die über den Monat so auflaufen und packe sie in Ordner mit einer Themensystematik, z.B. "Soft- und Hardware" oder "Reisekosten". Wenn dann die Steuermeldung fällig ist, brauche ich die Belege für alle Themen, aber nur die des letzten Monats. Das sollte über eine "erweiterte Dateisuche" ja kein Problem sein. Pustekuchen.
Wenn man im Suchfeld "änderungsdatum:" mit "letzte woche" erweitert, wird "letzte woche" blau markiert, es ist also ein gültige Option. Jedoch "änderungsdatum: letzter monat" bleibt schwarz. Kennt er nicht. Wie bitte?
Na gut, es sollte eine Dokumentation mit allen gültigen Optionen geben. Doch die finde ich nicht mal für Englisch. Dafür den ermutigenden Hinweis, dass die englischen Optionen in anderen Sprachversionen von Windows nicht funktionieren. Mit "datemodified: lastmonth" besteht also auch keine Hoffnung.
Nur wenn es die Suchmöglichkeit nach dem letzten Monat im Englischen gibt, dürfte Microsoft das seinen deutschen Kunden nicht vorenthalten haben. Also probiere ich die verschiedenen Varianten des Adjektivs durch: "letzte", "letzter", "letzten" und siehe da, es wird endlich blau.
Der gültige Modifikator scheint also eine Antwort auf die Frage "Wann wurde die Datei geändert?" zu sein. Muss man halt wissen. Trotzdem sieht "änderungsdatum:letzten monat" irgendwie verkehrt aus.
Gespeichert unter: Systemadministration Dokumentation
MySQL startet nach Ubuntu-10.04-Update nicht mehr (28.5.2010)
Als Entwicklungsumgebung läuft bei mir ein Ubuntu 10.04 in einer Virtualbox. Die gestrige Softwareaktualisierung enthielt unter anderem ein Update der MySQL-Pakete. Leider blieb die Aktualisierung immer bei der Einrichtung von MySQL hängen.
Im Syslog fand ich folgende Meldungen:
May 28 11:07:35 vbox-dev mysqld: 100528 11:07:35 [Warning] Can't create test file /mnt/mysql/data/vbox-dev.lower-test
May 28 11:07:35 vbox-dev kernel: [ 5954.840470] type=1503 audit(1275037655.858:54): operation="mknod" pid=14264 parent=14132 profile="/usr/sbin/mysqld" requested_mask="c::" denied_mask="c::" fsuid=0 ouid=0 name="/mnt/mysql/data/vbox-dev.lower-test"
Die Dateiberechtigungen waren eigentlich korrekt gesetzt, der Benutzer mysql durfte Dateien anlegen in dem Verzeichnis. Aber durch einen Blogeintrag fand ich dann auf die richtige Spur: Apparmor ist der Bösewicht.
Da ich nicht das Standardverzeichnis für die MySQL-Datenbanken verwende, fehlte eine Regel in der Konfiguration von MySQL für Apparmor
# Datei /etc/apparmor.d/usr.sbin.mysqld
/usr/sbin/mysqld {
...
# man muss die Regeln für das Standarddatenverzeichnis
/var/lib/mysql/ r,
/var/lib/mysql/** rwk,
# ersetzen durch eine Regel für das eigene Datenverzeichnis
/mnt/mysql/data/ r,
/mnt/mysql/data/** rwk,
...
}
Danach Apparmor und MySQL neu starten:
/etc/init.d/apparmor restart
start mysql
Fehlermeldungen von Apparmor befinden sich in /var/log/kern.log. Hilfreich ist auch die Installation des Pakets apparmor-notify. Es zeigt in einem Popup-Fenster auf dem Desktop die durch Apparmor blockierten Zugriffe.
Auf ubuntuusers.de gibt es mehr Informationen zu Apparmor.
Gespeichert unter: Systemadministration
Ein mysteriöser PHP-Bug: Doppelpunkt statt 0 bei Float-Rundung (23.12.2009)
Sowas Schräges hab ich noch selten erlebt. Ein Fehler, der reproduzierbar ist, aber doch nicht immer. In bestimmten PHP-Versionen gibt es beim Konvertieren oder Runden von Floats das Phänomen, dass aus '19' ein '18.:' wird (bei reddit nennt es jemand ASCII rounding mode, da PHP die Periode .999999 ASCII57='9' zu ASCII58=':' rundet).
Allerdings passierte das in unseren Tests nicht bei jedem Aufruf, sondern mal bei 3/4 aller Aufrufe, mal bei jedem vierten (genauere Berechnungen mit bcmul() etc. reduzierten die Häufigkeit). Es gibt einen offenen Eintrag im PHP-Bugtracker, der auf das Problem hinweist (#47304). Nur stammt der bereits vom 4. Februar. Seitdem kamen nur weitere obskure Hinweise dazu. Kurzfristig half auch mal ein Neustart von Apache, um den Fehler zu eliminieren. Aber am nächsten Tag trat er wieder auf. Dauerhaft erfolgreich waren wir nur mit der Rückkehr zu PHP 5.2.6.
Ein Decimal-Typ wie in Python ist doch was Feines.
Gespeichert unter: Programmierung Systemadministration