UNIXwork

Ab morgen, dem 14. Dezember, verkauft Apple den iMac Pro. Dieser soll ihre Pro-Kundschaft zufrieden stellen, da Apple sonst keine aktuelle und auch keine brauchbare Hardware im Angebot hat.

Im Vergleich mit dem gewöhnlichen iMac hat die Pro-Variante deutlich mehr Rechenleistung. Statt den Mittelklasse-CPUs wie dem i5 oder i7 verbaut Apple im iMac Pro den neuen Xeon W. Als GPU kommt eine Vega 56 zum Einsatz, die sicherlich auch mehr Leistung bringt.

Generell sehen die Specs beeindruckend aus. Ich hab da aber gewisse Bedenken, und möchte die für die Nachwelt festhalten, bevor es irgendwelche Reviews gibt.

Ich kann mir nicht vorstellen, dass Apple es schafft, diese Hardware vernünftig zu kühlen. Und ich denke das, weil Apple schon eine Weile nur noch Flüssigaluminium-Spender baut. Auch der aktuelle Mac Pro in Eimerform kann seine Abwärme nicht wegtransportieren. Die Folge ist, dass die Leistung gedrosselt werden muss. Eine Workstation drosselt aber nicht! Den Xeon W im iMac Pro gibts mit einer TDP bis 140W. Das Gehäuse ist viel zu kompakt um das zu kühlen. Das gleich gilt für die GPU.

Schon der normale iMac hat ein viel zu schwaches Kühlungssystem. Dieses ältere Video zeigt, wie ein iMac beim Gaming nach paar Minuten die GPU stark drosselt. Oder in diesem Forum wird über Drosselung des 2017er iMac berichtet. Da der neue iMac Pro eine deutlich höhere Leistungsaufnahme hat, kann dies auch nicht mit einem optimierten Kühlungssystem, welches Apple verspricht, gekühlt werden. Zumindestens nicht so, dass der iMac Pro längere Zeit volle Leistung bringen kann. Die einzige Frage ist nur noch, wie viele Minuten man ungedrosselt hat. Ich sage voraus, es werden 2 Minuten sein. Vielleicht auch 3.

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.

Für den Zugriff auf Extended Attributes hat macOS die Syscalls listxattr, getxattr, setxattr und removexattr. Sie heißen genauso wie die Linux-Syscalls und funktionieren auch fast genauso, nur haben sie ein paar Parameter für Options mehr. Die Syscalls finden sich im Header sys/xattr.h.

Um den Inhalt eines Attributs zu erhalten, benutzen wir den Syscall getxattr:

ssize_t
getxattr(const char *path, const char *name, void *value, size_t size,
		u_int32_t position,
		int options);

Dabei gibt man den Dateipfad, den Namen des Attributs, einen Pointer auf einen Buffer sowie dessen Größe an. Wie im vorherigen Artikel erwähnt, haben macOS Extended Attributes keinen Namespace, daher ist name ein frei wählbarer Name. Mit value und size gibt man einen vorher allozierten Puffer und seine Größe an. Falls value NULL ist, wird von der Funktion nur die Länge des Inhalts zurück gegeben. Der Parameter position funktioniert nicht mit allen Typen von Attributen und sollte daher 0 sein. Der Parameter options kann abgesehn von 0 noch XATTR_NOFOLLOW oder XATTR_SHOWCOMPRESSION sein.

char *buf = malloc(1024);
ssize_t attrlen = ("file.txt", "myattribute", buf, 1024, 0, 0);
if(attrlen > 0) {
	printf("myattribute: %.*s\n", (int)attrlen, buf);
}

Attribute hinzufügen oder verändern geht mit setxattr.

int setxattr(const char *path, const char *name, void *value, size_t size,
		u_int32_t position,
		int options);

position sollte auch hier wieder 0 sein. Bei den options gibt es wieder XATTR_NOFOLLOW und die interessanten Options XATTR_CREATE, um zu erzwingen, dass das Attribut nur gesetzt wird, falls es noch nicht existiert, oder XATTR_REPLACE, um nur den Inhalt eines bereits existierenden Attributs zu ändern.

char *value = "Hello World!";
setxattr("file.txt", "myattribute", value, strlen(value), 0, 0);

Alle existierenden Attribute auflisten geht mit listxattr.

ssize_t listxattr(const char *path, char *namebuf, size_t size, int options);

Dies schreibt in den vorher allozierten Buffer die Namen aller Attribute, getrennt durch ein 0-Byte. Hier findet sich ein Beispielprogramm, welches alle Attribute einer Datei auflistet.

Unter macOS sind Extended Attributes wie unter den meisten Betriebsystemen einfache name/value-Paare. Im unterschied zu Linux oder FreeBSD haben die Attribute keinen Namespace wie user oder system sondern einfach nur einen frei wählbaren Namen.

Extended Attributes können mit dem Tool xattr angezeigt und modifiziert werden. Außerdem kann auch ls Extended Attributes anzeigen. Eine kleine Übersicht über xattr:

Namen aller Attribute oder oder mehrerer Dateien auflisten:

xattr file ...

Value eines Attributs ausgeben:

xattr -p attr_name file ...

Attribut setzen:

xattr -w attr_name attr_value file ...

Attribut entfernen:

xattr -d attr_name file ...

Alle Attribute entfernen:

xattr -c file ...

Außerdem zeigt ls -l@ an, ob und welche Attribute eine Datei hat.

Ein kleines Beispiel:

$ echo "hello" > test.txt
$ rm test.txt 
$ echo "Hello World" > hello.txt
$ echo test > test.txt
$ xattr -w mime_type "text/plain" hello.txt 
$ xattr -w author Olaf hello.txt 
$ xattr -w testxattr testvalue test.txt 
$ ls -l@
total 16
-rw-r--r--@ 1 olaf  staff  12  9 Dez 19:18 hello.txt
	author	 4 
	mime_type	10 
-rw-r--r--@ 1 olaf  staff   5  9 Dez 19:18 test.txt
	testxattr	 9 
$ xattr -p mime_type hello.txt 
text/plain

Positiv ist, dass das macOS tar Extended Attributes im Archiv speichert. Auch cp kopiert sie standardmäßig. Insgesammt scheinen Extended Attributes unter macOS generell ein lebendigeres Feature als unter anderen Betriebsystemen zu sein, denn sie werden vom Finder oder anderen Programmen auch benutzt.