Wenn man ein Verzeichnis liest und von allen enthaltenen Dateien die Extended Attributes erhalten will, gibt es zwei Möglichkeiten:
- Man fügt zum Verzeichnispfad den Dateinamen hinzu und nutzt den neu erhaltenen Pfad mit den Syscalls
listxattr
oder getxattr
.
- Mit dem Filedescriptor des Verzeichnisses und
openat
öffnet man die Dateien und nutzt dann flistxattr
und getxattr
.
Ich hab mich gefragt was schneller ist. Dazu habe ich ein kleines Testprogramm geschrieben. Dieses kann mit unterschiedlichen Preprocessor-Optionen kompiliert werden. So habe ich 4 Testprogramme erstellt. Für getxattr
und fgetxattr
jeweils ein Programm, das ein Attribut liest und eines das 32 Attribute liest.
Bei einem Verzeichnis mit 128.000 Dateien hab ich folgende Werte erhalten:
getxattr:1 getxattr:32 fgetattr:1 fgetattr:32
------------------------------------------------
246100055 654704421 456172044 749849574
230183311 663632162 457183706 769223423
247109480 654775136 440397212 743349119
Die Datei erst zu öffnen um dann fgetxattr
zu nutzen ist also langsamer. Erst als ich das Programm so modifiziert habe, dass es mehrere hundert Attribute liest, war es etwas schneller. Das ist jedoch ein eher unrealistisches Szenario. Allerdings war das ganze generell sehr schnell, so dass es eigentlich egal ist, welche Methode man anwendet.
Programmiertechnisch sind Extended Attributes unter Solaris nur Dateien, daher gibt es keine speziellen Syscalls für den Zugriff darauf.
Eine Attribut-Datei öffnen kann man mit openat. Hierfür benötigt man nur einen File-Descriptor der Datei, von der man ein Attribut öffnen will. Es muss dann nur noch das O_XATTR
-Flag zusätzlich angegeben werden. Man erhält einen gewöhnlichen File-Descriptor, aus dem wie gewohnt gelesen und geschrieben werden kann.
Hier ist ein kleines Beispielprogramm, dass ein Attribut ausliest und auf der Konsole ausgibt.
Die Liste aller Attribute erhält man, in dem man das Attribut-Verzeichnis ließt. Der Trick ist hier, dass man das "."-Verzeichnis relativ zur Datei mit dem O_XATTR
-Flag öffnet.
int attrdir = openat(file, ".", O_RDONLY|O_XATTR);
Hier ist ein Beispiel dafür.
Für andere Dateisystemoperationen wie z.B. unlink oder chown gibt es ebenfalls *at-Funktionen, die man in Kombination mit einem File-Desriptor des Attribut-Verzeichnis benutzen kann. Siehe unlinkat, fstatat, fchownat.
Anstatt zuerst eine Datei mit open
und danach mit openat
das Attribut zu öffnen, kann man auch attropen benutzen, die das ganze in einer Funktion zusammenfasst.
In Solaris sind Extended Attributes keine Key/Value-Paare, sondern werden als Dateien repräsentiert. Hinter jeder Datei im Dateisystem steckt eine weitere Datei-Hierarchie, die jedoch auf normale Dateien beschränkt ist, also keine Unterverzeichnisse oder Links erlaubt. Attribute sind somit nur Dateien, für die die selben Limits für die Dateigröße oder Namen gelten. Außerdem haben sie eigene Zugriffsrechte. Nur einen absoluten Pfad haben sie nicht.
Für den Zugriff auf Attribute über die Shell gibt es das runat Tool. Dieses macht nichts weiter als das Working-Directory auf das versteckte Attributverzeichnis zu setzen und dann ein gewünschtes Kommando auszuführen. Man kann auch einfach eine Shell für dieses Verzeichnis starten. Um die Attribute dann zu lesen, schreiben oder aufzulisten können prinzipiell alle Programme verwendet werden.
$ touch test.txt
$ runat test.txt sh
$ echo "xattr test string" > testattribute
$ echo "text/plain" > mime_type
$ ls
mime_type SUNWattr_ro SUNWattr_rw testattribute
$ cat testattribute
xattr test string
$ exit
Kommen wir zu der Unterstützung für Extended Attributes in den Standard-Unix-Tools.
-
mv erhält immer alle Attribute. Wenn mv eine Datei auf ein anderes Dateisystem verschieben will, und dort die Extended Attributes nicht repliziert werden können, wird die Operation abgebrochen und die Quelldatei wird nicht gelöscht.
-
ls zeigt mit der -@ Option ein @-Zeichen nach den Zugriffsrechten an, wenn eine Datei Extended Attributes besitzt.
-
cp und tar ignorieren standardmäßig Extended Attributes, auch hier hilft die -@ Option.
Dateisysteme werden nicht nur ZFS und UFS unterstützt, sondern auch NFS. Und betreibt man einen Solaris smb-Server werden die Extended Attributes dort auch über smb als NTFS Alternate Data Stream zur Verfügung gestellt.
Siehe auch: fsattr(5)
Um auf Extended Attributes in C zuzugreifen gibt es unter FreeBSD die extattr_*-Syscalls. Auch hier gibt es Varianten, die mit Pfaden arbeiten, welche für Filedeskriptoren und welche die im Falle eines symbolischen Links den Link selber betreffen.
Alle Funktionen erwarten als 2. Parameter ein int
für den Namespace. Hierfür gibt es die Makros EXTATTR_NAMESPACE_USER
und EXTATTR_NAMESPACE_SYSTEM
.
Um an alle Namen der Attribute zu kommen gibt es die Funktion extattr_list_file
(und noch die beiden anderen Varianten). Im Gegensatz zu Linux werden hier die Namen nicht einfach Null-terminiert hintereinander in den Buffer geschrieben, sondern vor jedem Namen steht zunächst ein einzelnes Bytes, welches die Länge des Namens angibt. Danach folgt der Name, jedoch ist dieser nicht Null-terminiert. Die anderen Funktionen sind alle recht trivial zu benutzen.
Da FreeBSD keine Tools hat, um Dateien mit ihren Extended Attributes zu kopieren, hab ich ein kleines Beispielprogramm geschrieben, dass alle Attribute aus dem User-Namespace von einer Datei auf eine andere kopiert.
Kommentare
Andreas | Artikel: Datenanalyse in der Shell Teil 1: Basis-Tools
Einfach und cool!
Danke Andreas
Rudi | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Peter | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Damit wird Nedit durch XNedit ersetzt.
Danke!
Olaf | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Anti-Aliasing hängt von der Schriftart ab. Mit einem bitmap font sollte die Schrift klassisch wie in nedit aussehen.
Einfach unter Preferences -> Default Settings -> Text Fonts nach einer passenden Schriftart suchen.
Peter | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Mettigel | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Ich hatte gedacht, dass der GX-415 im s920 deutlich mehr Dampf hat als der Raspi4.
Mein Thinclient verbraucht mit 16 GB RAM ~11 W idle, das ist das Dreifache vom RP4. Das muss man dem kleinen echt lassen... Sparsam ist er.
Olaf | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Ergebnisse von der Ultra 80 wären natürlich interessant, insbesondere im Vergleich mit dem rpi1.
kosta | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
ich hätt hier zugriff auf Ultra-80 4CPU 4GB 2x Elite3D.