Normale Attribute einer Datei sind Dinge wie der Besitzer und einfache Unix-Zugriffsrechte. Es gibt daneben aber noch erweiterte Dateisystemattribute. Das sind beliebige name/value-Paare, die man für Dateien setzen kann.
Linux unterstützt Extended Attributes in der Regel. Der Kernel muss das Feature aktiviert haben, was per Default der Fall ist, und das Dateisystem muss es ebenfalls unterstützen und gegebenenfalls mit einer bestimmten Option gemountet sein. Dies ist in gängigen Distributionen alles der Fall. Ich hab es unter CentOS, Debian, Ubuntu und openSUSE getestet und es ging alles. Die üblichen Dateisysteme (ext*, xfs, jfs, btrfs, f2fs) unterstützen Extended Attributes. Mit ZFS on Linux geht es auch. Allerdings unterstützt NFS unter Linux keine Extended Attributes.
Wie schon erwähnt hat jedes Extended Attribute einen Namen und einen Wert. Der Name besteht aus einem Namespace gefolgt von einem Punkt und dem eigentlichen Namen. Es gibt 4 Namespaces: user, trusted, security und system. Der user Namespace ist frei für alles benutzbar. Die anderen Namespaces werden unter anderem für SELinux (security) oder für Posix-ACLs (system) genutzt.
Um Extended Attributes zu modifizieren oder anzuschauen gibt es die beiden Commandline-Tools getfattr und setfattr. Unter Debian und Ubuntu müssen diese erst mit dem Paket attr nachinstalliert werden. CentOS und openSUSE haben die Tools out of the box dabei. Die Benutzung ist recht einfach.
$ echo "hello" > test.txt
$ setfattr -n user.test -v "xattr test string" test.txt
$ setfattr -n user.mime_type -v "text/plain" test.txt
$ getfattr test.txt
# file: test.txt
user.mime_type
user.test
$ getfattr -n user.test test.txt
# file: test.txt
user.test="xattr test string"
Auch einige andere Tools unterstützen Extended Attributes, leider jedoch nicht alle, oder sie können es, aber machen einen das Leben etwas schwerer. Verschiebt man eine Datei mit mv bleiben die Extended Attributes erhalten, falls das Zieldateisystem diese unterstützt. Wenn nicht werden diese heimlich ohne Warnung entsorgt. GNU cp kopiert sie standardmäßig nicht mit, allerdings mit der Option --preserve=xattr werden sie mitkopiert. Mit GNU tar muss man sowohl beim Packen als auch Entpacken die Option --xattrs angeben. Und wenn man mit Gnome über die GUI ein Archiv erstellt, werden keine Extended Attributes gespeichert. Nautilus hingegen kopiert sie brav mit.
Ich finde es ist eigentlich ein interessantes Feature, was erstaunlich wenig von Anwendungen genutzt wird. Eins der wenigen Beispiele wo Extended Attributes eingesetzt werden ist bei Apache, wo damit Mime-Types oder Charsets für Dateien festgelegt werden können.
Unter Linux kann man Man-Pages in html umwandeln und im Browser öffnen:
man --html=firefox ls
Dies wandelt die Man-Page für ls in html um und speichert dies in einer temporären Datei. Anschließend wird dann firefox mit entsprechendem Parameter aufgerufen.
Damit dies funktioniert muss groff installiert sein, was beispielsweise unter Ubuntu standardmäßig nicht installiert ist.
Mit xclip kann man von der Kommandozeile aus mit der X11-Zwischenablage interagieren. Das Tool kann seine Eingabe von stdin in die Zwischenablage speichern oder die Zwischenablage auf stdout ausgeben.
Folgendes Beispiel speichert die Ausgabe von ls in der Zwischenablage
ls | xclip -selection clipboard
Die Zwischenablage auf stdout ausgeben kann man mit
xclip -selection clipboard -o
Der Syscall stat wird benutzt um an Informationen wie Dateigröße oder Änderungsdatum einer Datei zu gelangen. Die Funktion erwartet als Argumente nur einen Dateipfad und einen Buffer. Daneben gibt es noch die Variante fstat, die statt eines Dateipfades einen Filedescriptor erwartet, und fstatat, die den Filedescriptor eines geöffneten Verzeichnisses und einen Pfad relativ zu dem Verzeichnis erwartet.
int stat(const char *restrict path, struct stat *restrict buf);
int fstat(int fildes, struct stat *buf);
int fstatat(int fd, const char *restrict path,
struct stat *restrict buf, int flag);
Mich hat jetzt ein Performancevergleich zwischen den Funktionen interessiert. Zum einen für den Fall, dass man für jede Datei in einem Verzeichnis stat aufrufen will. Hier würde sich der Einsatz von fstatat anbieten. Der andere Fall wäre, wenn man eine Datei öffnen und stat-en will. Um dies zu testen hab ich ein primitives Programm geschrieben, dass man hier findet. Das Programm erwartet als Argument einen Pfad zu einem Verzeichnis, welches es zunächst ließt. Danach führt es 4 Tests durch und misst für jeden die Zeit:
- test_stat: Für jede Datei des Verzeichnisses wird
stat aufgerufen.
- test_fstatat: Für jede Datei wird
fstatat aufgerufen.
- test_open_stat: Jede Datei wird mit
open geöffnet und danach noch stat aufgerufen.
- test_fstat: Jede Datei wird geöffnet und
fstat aufgerufen.
Ein kleiner Test unter Linux ergab:
test 195 files:
test_stat
time: 496386 ns
test_fstatat
time: 246039 ns
----------------------------------------
test_open_stat
time: 1106593 ns
test_open_fstat
time: 885549 ns
Ähnliche Ergebnisse konnte ich auch unter FreeBSD und Solaris, mit Festplatten und SSDs, reproduzieren. Der Vergleich zwischen test_stat und test_fstatat zeigt, dass fstatat deutlich schneller ist. In beiden Tests wird auch nur pro Datei jeweils ein Syscall aufgerufen. Bei test_open_stat und test_open_fstat wird in beiden Fällen zunächst open benutzt um die Datei zu öffnen und es zeigt sich, dass in diesem Fall fstat auch schneller ist als stat, allerdings fällt der Unterschied hier nicht so sehr ins Gewicht.
Microsoft sorgt neuerdings öfter mal für Überraschungen. Diesmal veröffentlichen sie einen Texteditor für Linux und OS X, der trotz seines Namens nichts mit der Visual Studio IDE zutun hat.
Unter Scientific Linux 7 ließ sich Visual Studio Code problemlos starten. Der Editor setzt auf Chromium auf, was ihn zwar halbwegs plattformunabhängig macht, jedoch fühlt sich das Userinterface teilweise träge an. Zumindestens die Menüs werden etwas langsam gerendert.
Vom Funktionsumfang ist Visual Studio Code recht gut ausgestattet. Syntaxhighlighting für viele Sprachen, ein bisschen Codecompletion, Integration von git und Debugging für Mono- und Node-Anwendungen. Interessant ist auch die Markdown-Preview-Funktion, die bei mir aber nur funktionierte, wenn die Datei auf .md endete. Für C/C++ kann der Editor aber bei weitem nicht mit einer IDE mithalten.
Visual Studio Code kann man hier downloaden.