kaiser-edv.de » Tipps & Tricks » Helios » dateimanipulation-in-shares.html

Tipp: [Helios] Mit der Shell innerhalb EtherShare Volumes arbeiten     (10. Dezember 2003 — tk)

Anbei ein paar grundsätzliche Überlegungen zum Thema und ein Link auf ein paar Skriptschnipsel, die die auftretenden Problematiken entschärfen.

Sollen Dateien und Ordner nicht von Mac- oder Windows-Clients aus sondern direkt am Server mit Mitteln des Unix-Betriebsystems manipuliert werden, ist auf mehrere Dinge zu achten:

Zu jeder vollwertigen von einem Mac oder PC kommenden Datei existiert ein Pendant im .rsrc-Unterordner. In diesem werden Macintosh-Metadaten wie bspw. das Erstellungsdatum, Finder-Etiketten oder Finder-Flags wie bspw. »unsichtbar« gespeichert. Zusätzlich auch die Resource Fork, so die Datei eine besitzt.

Zu guter letzt speichert EtherShare auch noch interne Metdaten darin ab, bspw. die sogenannte File ID oder im Falle eines Verzeichnisses Directory ID. Diese IDs werden zwar primär in der Schreibtischdatei des Volumes (${VOLROOT}/.Desktop) gespeichert aber eben auch parallel in der korrespondierenden .rsrc-Datei, um im Bedarfsfall die Schreibtischdatei auch aus den Metadaten der Dateien rekonstrukieren zu können (siehe auch DesktopDB Inkonsistenzen prüfen)

Auf was ist also zu achten, wenn man direkt auf dem Server vor der Notwendigkeit steht, Dateien und Verzeichnisse innerhalb von EtherShare-Volumes anzufassen?

1. Die korrespondierenden Dateien im Unterordner .rsrc sind immer ebenfalls zu beachten, da sie sowohl Mac-spezifische als auch intern für den afpsrv wichtige Metadaten enthalten und nicht zuletzt gegebenenfalls die Resource Forks der Dateien enthalten könnten.
2. Wenn Manipulationen innerhalb EtherShare-Volumes direkt mit Unix-Bordmittel vonstatten gehen, dann geschieht das für den EtherShare desksrv ebenso unbemerkt wie für die einzelnen afpsrv oder pcshare Prozesse, die die Clients bedienen. Daraus resultieren potentiell Inkonsistenzen der DesktopDB des Volumes als auch Probleme hinsichtlich Locking.
3. Werden schließlich noch die sogenannten OPI Events des Image Servers benutzt, sei es für scriptsrv-Aktionen oder für Asset Management Systeme wie Cumulus, MediaBeacon oder Chalco.net, so ist darauf zu achten, die passenden OPI Events ebenfalls zu schicken, wenn Dateien oder Verzeichnisse erstellt, verschoben, umbenannt oder gelöscht werden.

Die Probleme 1) und 2) können sehr gut durch die Verwendung der Helios Desktop Utilities umgangen werden. Anstatt bspw. eine Datei wie von Unix gewöhnt per mv umzubenennen, würde man das entsprechende dt mv Pendant benutzen:

${HELIOSDIR}/bin/dt mv "${Quelle}" "${Ziel}"

Will man eine neue Datei erstellen, bspw. um eine Log-Mitteilung hineinzuschreiben, erzeugt man diese per dt touch und vergibt anschließend noch einen passenden FileType und Creator Code, damit die Datei am Mac per Doppelklick mit dem passenden Programm — in diesem Beispiel BBEdit — geöffnet wird:

${HELIOSDIR}/bin/dt touch "${LogFile}"
${HELIOSDIR}/bin/dt set -t 'TEXT' -c 'R*ch' "${LogFile}"
echo "${Logtext}" >"${LogFile}"

Weitere sehr detaillierte Hinweise zu den diversen Optionen der DT Utilities finden sich im EtherShare Manual — Abschnitt 9

Um Problem 3) zu adressieren existieren seit den Updates u0313/u0314 zu diesem Zweck weitere Aufrufparameter für opitouch. Nach Erzeugen einer neuen Datei — z.B. /raid1/es/testfile — ist es sinnvoll, Folgendes abzusetzen

${HELIOSDIR}/bin/opitouch sendclose '/raid1/es/testfile'

damit die nachgeschalteten auf OPI Events aufbauenden Mechanismen ebenfalls davon in Kenntnis gesetzt werden.

Copyright © Thomas Kaiser, 2003 (erstellt am Mittwoch, 10. Dezember 2003)

Dieser Beitrag kann durch jedermann gemäß den Bestimmungen der Lizenz für die freie Nutzung unveränderter Inhalte genutzt werden. Die Lizenzbedingungen können unter http://www.uvm.nrw.de/opencontent abgerufen oder bei der Geschäftsstelle des Kompetenznetzwerkes Universitätsverbund MultiMedia NRW, Universitätsstraße 11, D-58097 Hagen, schriftlich angefordert werden.