Dauert cp mal wieder länger? Hat ja leider auch nicht mal eine Fortschrittsanzeige.
Mit dem Tool progress kann man sich jedoch für Programme wie cp, dd und andere den Fortschritt und Kopiergeschwindigkeit anzeigen lassen. Das Programm durchsucht /proc nach bestimmten Programmen und schaut für diese jeweils welche Dateien geöffnet sind und zeigt dann den Fortschritt für die größte Datei. Also wärend cp läuft einfach in einem 2. Terminal progress -w aufrufen:
$ progress -w
[25534] cp /storage/bigfile
67.4% (673.8 MiB / 1000 MiB) 22.2 MiB/s remaining 0:00:14
Kopiert man allerdings mehrere Dateien mit cp, dann wird natürlich nur der Fortschritt der aktuellen Datei angezeigt.
Extended Attributes sind auch unter FreeBSD name/value-Paare, die man beliebig für alle Dateien setzen kann. Im Unterschied zu Linux ist die Größe nicht auf wenige Kilobyte beschränkt. Desweiteren gibt es auch hier Namespaces (user und system), diese sind jedoch nicht Teil des Attribut-Namen.
Unter FreeBSD gibt es 4 Tools für den Zugriff auf Extended Attributes: getextattr, lsextattr, rmextattr, setextattr. Diese erwarten nach den optionalen Flags als erstes Argument immer den Namespace. Hier ein kleines Beispiel:
$ echo "hello" > test.txt
$ setextattr user test "xattr test string" test.txt
$ setextattr user mime_type "text/plain" test.txt
$ lsextattr user test.txt
test.txt mime_type test
$ getextattr user test test.txt
test.txt xattr test string
Leider unterstützen die Userland-Tools wie cp und tar keine Extended Attributes.
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.
Beim Zugriff über ssh auf ein etwas älteres Unix wie z.B. Solaris 10 erhält man in vi oder manchen anderen Terminal-Anwendungen eine Fehlermeldung wie
xterm-256color: Unknown terminal type
Die Anwendung ist dann meistens nicht oder nur eingeschränkt benutzbar.
Die triviale Lösung ist einfach die TERM-Umgebungsvariable auf xterm zu setzen. Wenn man das nicht immer manuell machen will, kann man das einfach in der .profile Datei (oder .bash_profile, wenn die Login-Shell die bash ist) folgendes hinzufügen:
if [ $TERM = "xterm-256color" ]; then
TERM=xterm
export TERM
fi
Wenn man root-Rechte auf dem Server hat, gibt es auch noch eine andere Lösung. Es gibt eine Terminfo-Datenbank, die für die verschiedenen Terminal-Typen die Fähigkeiten enthält. Den fehlenden Eintrag für das xterm-256color Terminal kann man einfach hinzufügen.
Unter Solaris 10 finden sich die Terminfo-Dateien unter /usr/share/lib/terminfo. Dort gibt es für jeden möglichen Anfangsbuchstaben ein Verzeichnis, die xterm Einträge sind daher unter /usr/share/lib/terminfo/x. Dort muss eine Datei xterm-256color rein. Die ganz einfache Lösung wäre einfach die xterm-Datei zu kopieren. Ich hab hingegen die xterm-256color-Datei von einem Solaris 11 dort eingefügt. Beides funktioniert und sobald diese Datei da ist, erkennen Anwendungen auch das xterm-256color-Terminal.
GNU Screen ist eine Art Fenstermanager für die Konsole, der es erlaubt, mehrere getrennte Sitzungen innerhalb eines Terminals zu benutzen. In Zeiten grafischer Terminal-Emulatoren wird dies vielleicht nicht so oft gebraucht, ein weiteres sehr nützliches Feature ist jedoch, dass man eine Screen-Session unterbrechen, und später wieder fortsetzen kann. Die unterbrochenen Sessions laufen im Hintergrund weiter, auch wenn die Shell, von der aus man ursprünglich screen gestartet hat, beendet wird. Dies ist sehr praktisch, wenn man z.B. per ssh auf einem entfernten Rechner ein Programm längere Zeit laufen lassen will.
Nach dem Start von screen erhält man eine Shell die in einer Screen-Session läuft. Diese kann mit Strg+A gefolgt von D getrennt werden und später mit screen -r wieder hergestellt werden.