UNIXwork

Ein kleines Update für dav, welches 4 Probleme behebt.

• Die Windows-Version war quasi vollständig kaputt. Zwar ging dav oft, bei falscher Planetenkonstellation jedoch nicht. Grund war, dass für einem String nicht genug Speicher für die Terminierung alloziert wurde, wodurch bei allen Dateisystemoperationen ein Out-of-bounds Write geschah.

• Kompatiblität mit Owncloud/Nextcloud wurde verbessert. Diese WebDAV-Server halten sich leider nicht genau an die WebDAV-Spezifikation und geben bei einem PUT-Request den Statuscode 404 zurück, wenn eine Parent-Collection nicht existiert. Bisher hat dav in dem Fall den Status-Code 409 erwartet, wie es die Spezifikation auch vorschreibt. Es ist jedoch kein Problem in dem Fall auch 404 so zu behandeln. Somit können dav und dav-sync beim Dateiupload auch bei Owncloud und Nextcloud erkennen, dass die Parent-Collection nicht existiert, und sie dann automatisch erstellen.

• Bei den dav-sync Befehlen um Tags zu bearbeiten, hat bisher die -s Option nicht funktioniert.

• Wenn bei einem Repository <decrypt-name> eingeschaltet war, wurden zwar Dateinamen entschlüsselt, jedoch nicht ganze Pfade. Dies wurde behoben, so dass mit dieser Einstellung auch die Pfade entschlüsselt werden.

dav Projektseite SourceForge Projektseite

Es hat zwar etwas länger gedauert, aber nun gibt es ein neues Release von dav. Es werden vor allem die verschiedenen Plattformen nun besser unterstützt. Eine falsche Verwendung von vaargs hat dazu geführt, dass manche Betriebsystem-Compiler-Kombinationen nicht richtig funktioniert haben. Außerdem lässt sich dav jetzt unter macOS ohne openssl-Header kompilieren. Abgesehn von Xcode wird dort also keine zusätzliche Abhängigkeit benötigt. Und unter Windows werden jetzt Unicode-Dateinamen unterstützt.

Dazu haben die Tools ein paar kleine neue Features erhalten.

dav

• Mit dem export-Befehl kann eine Collection gedownloadet, und daraus ohne Umwege eine TAR-Datei erstellt werden. Mit import hingegen kann der Inhalt einer TAR-Datei geuploadet werden.
• Die Befehle set-property und get-property unterstützen nun beliebigen XML-Content als Wert für die Properties.
• Der get-Befehl erhält die neue Option -K, die verhindert, dass Dateien gedownloadet werden, die lokal bereits existieren.

dav-sync

• Einzelne Sync-Befehle (pull, push, archive) können für ein SyncDirectory per Konfigurationsdatei deaktiviert werden, um unabsichtliches falsches Synchronisieren zu verhindern.
• Experimenteller Support für File-Tagging: Dateien können mit Tags versehen werden und beim syncen können Filter auf Tags angewendet werden. Unter macOS werden auch die nativen Tags, wie man sie im Finder sieht, unterstützt.

dav Projektseite SourceForge Projektseite

WebDAV kennt zwei Arten von Locks: Exclusive und Shared Locks. Ein Exclusive Lock wird vom Server pro Resource immer nur einem User gestattet. Dies verhindert effektiv, dass andere User eine Ressource überschreiben. Shared Locks hingegen können von mehreren Usern gleichzeitig erhalten werden. Damit sind Shared Locks kein Schutz davor, dass andere eine Ressource überschreiben, sondern sind eher da, um andere Clients zu informieren, dass die Datei gerade in Bearbeitung ist.

Ein Lock bezieht sich entweder auf eine einzelne Ressource, oder auf ganze Collection. Bei letzterem hat man auch die Wahl, ob nur alle direkten Kind-Ressourcen gelockt werden sollen, oder alles was sich unterhalb der gelockten Collection befindet.

Kann ein Client einen Exclusive Lock erfolgreich erstellen, erhält er vom Server ein Locktoken. Dieses Locktoken muss bei allen Schreiboperationen auf die gelockte Resource angegeben werden.

In dav werden bisher nur Exclusive Locks unterstützt. Hierfür gibt es für das Tool dav die Befehle lock und unlock, um Resourcen zu sperren oder zu entsperren. Das Tool dav-sync kann bei Bedarf auch die ganze Collection locken, in dem man die passende Option angibt oder in der Konfigurationsdatei Locking aktiviert.

Um mit dav eine Ressource zu sperren benutzt man den Befehl lock und übergibt die URL der Ressource. Optional kann auch ein Lock-Timeout angegeben werden. Wenn die Ressource erfolgreich gelockt werden konnte, wird auf stdout das Locktoken ausgegeben.

$ dav lock myserv/file.txt
opaquelocktoken:cde48dcb-c860-0512-a770-x38b4f980dbc

Das Locktoken muss man unbedingt irgendwo speichern oder es muss im Terminal zumindestens in Sichtweite bleiben. Denn verliert man das Locktoken ist vor Ablauf des Timeouts kein Schreibzugriff auf die Ressource mehr möglich, was ungünstig bei einem unendlichen Timeout ist. In diesem Fall müsste der Serveradministrator im Webserver den Lock entfernen.

Hat man nun das Locktoken, kann dies bei allen dav-Befehlen, die Schreibvorgänge ausführen, angeben. Also z.B. um eine gelockte Ressource zu überschreiben, gibt man mit der -L Option das Locktoken an:

$ dav put -L opaquelocktoken:cde48dcb-c860-0512-a770-x38b4f980dbc myserv/file.txt localfile.txt

Eine Ressource unlocken kann man mit dem unlock Befehl. Dabei muss auch das Locktoken angegeben werden. Falls nicht mit der -L Option angegeben wird, liest dav von stdin das Locktoken.

$ dav unlock -L opaquelocktoken:cde48dcb-c860-0512-a770-x38b4f980dbc myserv/file.txt

Es ist empfehlenswert, das Locktoken direkt in einer Datei zu speichern.

$ dav lock myserv/file.txt > locktoken
$ dav put -L `cat locktoken` myserv/file.txt uploadthisfile.txt
$ dav unlock myserv/file.txt < locktoken

Um in dav-sync WebDAV-Locks zu nutzen, kann man entweder bei den Synchronisationskommandos (pull, push, archive) die Option -l angeben, oder man aktiviert standardmäßig Locking für das Sync-Verzeichniss, in dem man in der Datei $HOME/.dav/sync.xml innerhalb eines <directory>-Elements folgendes einfügt:

<directory>
	...
	<!-- enable lock for pull command -->
	<lock-pull>true</lock-pull>
	
	<!-- enable lock for push/archive command -->
	<lock-push>true</lock-push>
</directory>

Natürlich ist es auch möglich, nur pull oder nur push mit Lock zu nutzen.

Wenn dav-sync die Collection lockt, wird im Verzeichnis $HOME/.dav temporär eine Datei (locktoken-$syncdir.txt) angelegt, die das Locktoken enthält. Sollte dav-sync unerwartet beendet werden, kann man somit noch manuell die Collection unlocken. Wenn dav-sync sauber terminiert, wird automatisch die Collection entsperrt und die temporäre Datei entfernt.

Ein kleines dav Update, welches nur einen Bug fixt, der nur unter Windows auftritt. Der Fehler verursachte, dass die Befehle get und list nicht mit der -R Option funktionierten.

Die Änderungen betreffen nur die Windows-Version, durch ein #ifdef sind diese auf anderen Plattformen nicht aktiv. Als Nicht-Windows-User kann man sich das Update also sparen. Ich schätze, ich muss wohl ober übel in Zukunft mehr unter Windows testen.

dav Projektseite SourceForge Projektseite

Die integrierte Verschlüsselung von dav ist für den Benutzer weitestgehend transparent, bis auf in den Befehlen copy und move in der aktuellen Version 1.1. Bisher sind diese Befehle nur low level WebDAV, das heißt, es wird wirlich nur ein WebDAV COPY oder MOVE ausgeführt. Schauen wir uns dav copy und dav move erstmal an:

dav copy [-pcO] [-L <lock>] <url> <url>
dav move [-pcO] [-L <lock>] <url> <url>

Beide Befehle sind von der Benutzung her gleich, nur dass copy eine Kopie erstellt und move eine Ressource verschiebt. Wie man sieht, haben beide Befehle die Flags -p und -c, mit denen Verschlüsselung aktiviert und deaktiviert werden kann. Dies bezieht sich jedoch nur auf die Pfad-Auflösung.

Das Positive ist schon mal, dass mit aktivierter Verschlüsselung die Ziel-URL (das letzte Argument) auch randomisiert wird. Bei verschlüsselten Ressourcen ist der Dateiname, den der Server sieht, nur ein zufälliger String, während der Name, den dav verwendet, verschlüsselt in den Properties gespeichert wird. Das Problem ist, dass copy/move nicht diese Property anpassen, sondern nur die Properties der Source-URL kopieren, wie es von WebDAV COPY/MOVE gefordert ist. Das hat zur Folge, dass der Dateiname, den dav verwendet, bei verschlüsselten Ressourcen sich nicht durch dav copy/move ändert.

$ dav list -l cryptrepo
-c    32 bytes  Dec 11 19:54  test.txt
$ dav move secrepo/test.txt cryptrepo/newname.txt
$ dav list -l cryptrepo
-c    32 bytes  Dec 11 19:54  test.txt

Schlimmer wird es noch mit copy, wenn die Ziel-URL die selbe Collection ist:

$ dav copy cryptrepo/test.txt cryptrepo/copy.txt
$ dav list -l cryptrepo
-c    32 bytes  Dec 11 20:10  test.txt
-c    32 bytes  Dec 11 19:54  test.txt

Wer sich jetzt fragt, wie man die richtige Datei löschen kann: mit deaktivierter Verschlüsselung sieht man die echten Dateinamen und anhand des lastmodified-Datums kann man die richtige Datei identifizieren.

Möchte man eine verschlüsselte Datei umbenennen, also den verschlüsselten Namen ändern, gibt es einen einfachen Workaround.

Als erstes erstellt man mit dav put eine neue Datei mit dem gewünschten Namen.

$ dav put cryptrepo/newfile.txt -
^D

Dann holt man sich den Inhalt der crypto-name Property.

$ dav get-property cryptrepo/newfile.txt idav:crypto-name
z7qDCHM65EuUSooCt22yaI2d2zwKDdPDlgte23ATkUo=

Die Datei kann dann wieder gelöscht werden.

$ dav rm cryptrepo/newfile.txt

Die verschlüsselte Datei, die man umbenennen möchte, bekommt jetzt den Inhalt der crypto-name Property.

$ dav set-property cryptrepo/test.txt idav:crypto-name z7qDCHM65EuUSooCt22yaI2d2zwKDdPDlgte23ATkUo=

Und schon denkt dav, dass die Datei newfile.txt heißt.