maplesteve.com

Mac OS X: WebDAV protocol not supported (solved)

When you see in your console log messages like

11.02.12 17:36:41,009 webdavfs_agent: network_mount: WebDAV protocol not supported; file: /SourceCache/webdavfs/webdavfs-322/ mount.tproj/webdav_network.c; line: 3131

then this doesn’t necessarily mean, that Mac OS X suddenly stopped understanding the WebDAV server it could mount minutes ago. In fact it’s more likely, that the problem lies on the server side and the DAV config is incomplete.

Since the Mac OS web DAV client isn’t really chatty about what’s (wr)on(g) here, you should use e.g. cadaver - a unix WebDAV client for debugging.

The client can properly connect to the DAV server which you can see by the result code (“200”) in the apache log file:

"OPTIONS / HTTP/1.1" 200 250 "-" "cadaver/0.23.3 neon/0.29.0"

But the client tells you, that there’s something wrong anyhow, which you can verify again in the apache log:

"PROPFIND / HTTP/1.1" 405 508 "-" "cadaver/0.23.3 neon/0.29.0"

The result code “405” means “Method not allowed” - does the client try to talk to the DAV server via incorrect command and Mac OS therefore reports the “not supported” message? No, it’s just that the DAV server doesn’t know how to handle the DAV protocol properly.

So go and check your server config. When I upgraded Plesk from version 10.2 to 10.4, the upgrade process didn’t catch all the relevant vhost.conf files and therefore left me with a half configured DAV server. The problem is, that Plesk 10.4 uses a diefferent directory layout under /var/www/vhosts/ and I had to manually copy and configure the vhost.conf files to their new place to be.

OCR speed: DevonThink Pro Office vs. ScanSnap S1300M

That the integrated OCR engine, that ships with DevonThink Pro Office is only the single-core version is known - it’s due to licensing issues and DevonThink would have to charge a lot more if they made available the multi-core version.

I wanted to know, if the Abby FineReader which ships with the Fujitsu ScanSnap S1300M utilizes the multi-core capability. So I ran some tests.

Though I dont’t think, it uses multiple cores, I found the ScanSnap to be 4x faster.

For a 2,5 pages document, the ‘normal’ workflow (use the built-in OCR of DT) takes a lot more time compared to a slightly different workflow, where the OCR is done by the ScanSnap software. The actual result for the OCR job where 48 seconds vs. 12 seconds.

The caveat is, that this approach doesn’t have the queue feature, that DT has, so that it’ll have to finish the OCR process before you can feed it the next document. But since the OCR is 4 times faster, this is a minor one, since it will increase your overall throughput.

If you want to follow this, just check “convert to searchable PDF” in the in the profile settings in ScanSnap. Then uncheck the same in the DevonThink Pro Office preferences.

How to solve slow rrdtool graph creation

After upgrading my cacti server to Mac OS X Lion, the graphs in my Cacti installation needed a very long time to render and the CPU usage of rrdtool spiked – somehow blocking the whole machine.

The rrdtool which is needed by cacti has been installed via Fink, which is a fine project maintaining all the usual *nix tools, that don’t come with Mac OS X. Fink gives you the convenience of a Debian package manager and makes installing additional software a breeze.

Because I didn’t know exactly which program was responsible for the slow rendering, I dumped the whole fink tree which is normally located at /sw and started over with a fresh install. After fink completed all the compiling an installation I had a fast cacti again. Since I didn’t update the fink packages regulary, I was sure, that some bugfixes in the newer versions resolved the slowness problem.

After the recent update of Lion to 10.7.2, I had to realize, that the rendering was totally slow again. So I thought, that an update of rrdtool and the other needed tools should do the trick again. Unfortunately there was no newer version of the tools as those which where already installed.

After trying some things (which didn’t help), I looked for a way to circumvent the dump-everything-and-spend-another-two-hours-reinstalling thing. Since there was no newer version for 10.7.2, there must be a different cause.

I figured out, that one of the following tools had to be the offending one:

• librrd4-shlibs
• rrdtool
• pango1-xft2-ft219 (dev, shlibs & the main one)
• freetype219 (main & shlibs)
• fontconfig2

So find their package name and remove them (example for ‘freetype’):

When you delete or remove a package via fink and then reinstall it again, fink makes use of the binary packages it produced during the former installation. (I tried the command-line switches to avoid this behaviour but had no luck.)

What helped, was to delete the packages from the cache directories (on my system this is at /sw/fink/10.7/stable/main/binary-darwin-x86_64/) and starting the fink install command again.

I think it’s safe to delete them all:

fink grabs the source and – since the binary package is no longer available – compiles everything from scratch.

Install the packages. It’s best to start with the main package (the one you were initially interested in), because the package management of fink will install additional ones automatically when needed:

After that, the rrdtool graph rendering was fast again. So my conclusion is, that even during minor updates of Mac OS X, underlying things can change that way, that programs don’t work as expected, if they were compiled on a different version of the system.

So, if your tools behave different after an update or upgrade, try a fresh compile of them first.

Deutscher Thesaurus für Lexikon in Mac OS 10.5 (Leopard)

Apple liefert leider keine deutschen Inhalte für das Lexikon mit. Einen deutschen Thesaurus sucht man daher vergeblich. Wolfgang Reszel schafft hier Abhilfe: er veröffentlicht ein Plugin für Lexikon, das Einträge von opthesaurus.de integriert. Funktioniert prima.

Link: OpenThesaurus Deutsch

In diesem Zusammenhang sei noch ein weiteres Plugin erwähnt:

dict.cc ist ein Wörterbuch Deutsch – Englisch und kann auf der Download-Seite heruntergeladen werden.

Problem mit Time Machine gelöst!

Nachdem das MacBook durch ein neues MacBook Pro ersetzt wurde, habe ich einen frischen Leoparden installiert, um es für die nächste Benutzerin aufzusetzen. Nach erfolgter Installation, Einrichtung und Umbenennung (‘Systemeinstellungen – Sharing – Gerätename’) fehlte als letzter Schritt nur noch die Aktivierung von Time Machine zwecks automatischem Backup auf unser Time Capsule.

Eigentlich total einfach: ‘Systemeinstellungen’ öffnen, ‘Time Machine’ wählen, Time Capsule auswählen fertig.

Denkste.

Das, was wor der Neuinstallation funktionierte, lief nicht mehr. Time Machine beschwert sich nachhaltig mit folgendem Dialog:

Time Machine:Das Image des Backup-Volumes konnte nicht aktiviert werden.

Hm. O.k. Das Sparsebundle auf der Time Capsule ‘hört’ ja auch noch auf den alten Namen (ich hatte dem macBook ja einen neuen gegeben). Vielleicht bringt das ja hier irgendwas durcheinander. Also Sparsebundle löschen – was nicht das File an sich löscht, sondern es nur deutlich verkleinerte.

Die Erwartungshaltung war, dass Time Machine ein neues Sparsebundle anlegt – was dann auch mal den neuen Namen reflektieren sollte. Passierte aber nicht; stattdessen o.g. Fehlermeldung. Was will TM denn eigentlich aktivieren, wenn noch gar nichts angelegt wurde? Konnte eigentlich nur daran liegen, dass es noch eine Verknüpfung zwischen altem Sparsebundle bzw. den Time Machine Einstellungen und dem MacBook gibt. Der Name des Sparsebundle besteht aus dem Gerätenamen sowie der MAC-Adresse der Ethernet-Schnittstelle. Das scheint Time Machine nicht automatisch auflösen zu können. Also ‘Terminal’ anwerfen, nach /Volumes/[Time_Capsule_Name] wechseln und ein beherztes

rm -rf [Name_des_zu_löschenden_Bundles].sparsebundle

absetzen. Danach muss dann noch ein weiteres File gelöscht werden, mithelfe dessen Time Machine offenbar eine Verknüpfung zwischen Backup und Rechner herstellt:

rm -rf .[MAC-Adresse_des_betreffenden_Rechners]

Damit waren alle Spuren der früheren Time Machine Einrichtung erfolgreich beseitigt und TM verrichtete nach dem normalen Setup einwandfrei seinen Dienst.

Fazit: Apple sollte Time Machine beibringen, auf derartige Situationen vernünftig zu reagieren. Es sollte bemerken, dass eine bestehende Backup-Einrichtung vorhanden ist und anbieten, diese zu löschen.