Hallo Jürg,
> Wie schon in einem anderen Beitrag geschrieben reicht es aus wenn der
> Schreibtisch neu aufgebaut und das Volume ungemountet und dann wieder
> gemountet wird (Symtombekämpfung). Aber denoch:
Das ist _niemals_ eine gute Idee. File- und Directory-ID-Inkonsistenzen billigend in Kauf zu nehmen braucht es doch gar nicht.
Man sollte sich klar sein, daß diese IDs ein essentielles Merkmal sind, anhand dessen unter dem MacOS (und ebenfalls innerhalb mancher Helios-Subsysteme, bspw. Fallback beim OPI-Replacement auf Suche nach File-ID) Referenzierungen auf Dateien/Ordner stattfinden.
Das Geniale an diesem ID-Konzept im Gegensatz zu einer Referenzierung nur anhand eines Pfades (Unix: /data/bla/blubb/datei.txt oder Windows: c:\\bla\blubb\datei.txt) ist, daß man Dateien auch dann noch eindeutig findet, wenn sie verschoben oder umbenannt wurden. Dieses elementare Konzept steckt seit den Anfangstagen im Mac und wird von Anwendungen und dem Finder seitdem rege genutzt.
Seitens MacOS X bedient sich bspw. der Alias Manager dieser IDs oder auch der Finder (der seit MacOS X sogar wieder vermehrt -- was v.a. allem Xinet-Anwender zu spüren bekamen, weil Fullpress respektive K-AShare eine recht "einfache" ID-Implementierung benutzen). Anwendungen benutzen die IDs bspw. um Dateien zu speichern (es ist am Mac ja bspw. völlig legal, eine gerade geöffnete Datei extern umzubenennen oder innerhalb eines Volumes zu verschieben) oder platzierte Bilddaten zu referenzieren, etc.
Kurz: Eine funktionierende ID-Implementierung ist schlicht und ergreifend essentiell. Helios hat eine solche in Form der Desktop Databases je Volume geschaffen und passende Mechanismen bereitgestellt, daß man diese auch permanent konsistent halten kann (Zugriff via EtherShare/PCShare oder unter Unix Einsatz der "DT Utilities" -- vgl. bspw. mit
http://kaiser-edv.de/...ion-in-shares.html). Also gibt es eigentlich wirklich keinen Grund, permanent korrupte Schreibtischdateien zu riskieren. Die Konsequenzen (bspw. beim OPI-Replacement) können nämlich teils katastrophal sein!
Probleme mit Anwendungen/Finder sind ebenfalls vorprogrammiert, solange man nicht andauernd die Schreibtischdateien parallel neu aufbaut. Letzteres darf aber immer nur Notlösung sein. Die Vermeidung solcher Zustände muß oberste Priorität haben.
>> Wenn weitere Info gewünscht, was da konkret passiert im Finder, kann ich
>> gerne ausführlicher werden...
>
> Ja! Bitte!
Dieses Phänomen mit "Datei kurz da und wieder weg", ist _meistens_ auf Folgendes zurückzuführen:
Der Finder holt sich erstmal vom Server das Directory Listing und zeigt die Dateien an. Dann guckt er sich die Dateien genauer an und bspw. bei Dateien, die Umlaute im Namen haben, erfolgt dann noch ein Lookup anhand des "Shortname" (hier entsteht bspw. ein Problem mit den aktuellen Helios AFP 3.1 Previews, weil Helios hier ein anderes Shortname Mangling Schema benutzt als Apple und Apple dieses ihr serverseitiges Schema knallhart auch irgendwo in die AFP-Client-Routinen von MacOS X reinkodiert hat) und der File- oder Directory-ID (FPResolve Call).
Klemmt es hier irgendwo, zeigt der Finder die Datei oder den Ordner einfach nicht mehr an. Und klemmen tut es automatisch immer dann, wenn irgendwas mit den IDs nicht mehr stimmt. Das kann auch vorkommen, *nachdem* die Schreibtischdatei bereits neu aufgebaut wurde aber der Mac *nicht* das/die betroffene(n) Volume(s) erneut gemountet hat (IDs werden auch client-seitig gecached).
>> Wenn gewünscht, führe ich gerne mal aus, wie ein taugliches Restore mit
>> untauglicher Backup-Software vorgenommen werden kann.
>
> Auch hier bin ich auf eine genauere Ausführung gespannt.
Erstmal zur Definition: "Untauglich" im Sinne von Helios-Konformität ist automatisch jede Software, die weder die Helios Desktop-Libraries lizensiert hat noch Gebrauch von den DT Utilities macht (meines Wissens gibt es also nur drei Lösungen, die sich "konform" nennen dürfen. Diese benutzen einen der beiden Wege, um die ID-Konsistenz nicht zu gefährden und bieten darüberhinaus deutlich mehr Komfort, wenn es um das Handling der klassischen Mac-Metadaten/Resourceforks geht, weil diese als Teil vollwertiger Mac-Dateien betrachtet werden).
Benutzt man so eine untaugliche Lösung, so sollte man sich ein kleines separates "Restore"-Volume einrichten. Da hinein sichert man dann Dateien aus dem Backup retour und zieht anschließend per Drag&Drop die Dateien an den ursprünglichen Ort, also dort, wo sie eigentlich hingehören (alternativ kann man das auch unter Unix auf dem Server direkt automatisieren per DT Utilities -- allerdings muß man hier ein bisserl aufpassen, wenn man nicht sicherstellen kann, daß beide Volumes immer dasselbe Dateinamen-Encoding -- "Altes Schema" vs. UTF-8 -- haben. Der grosse Vorteil der Unix-Methode ist, daß man sich bei diesem Ansatz auch bei Bedarf die originalen Eigentümerschaften und Berechtigungen der Dateien erhalten kann)
Arbeitet man so, dann hat man die ID-Inkonsistenzen nur innerhalb des Restore-Volumes, wo sie allerdings nicht stören, da das ja nur temporärer Zwischenspeicher ist.
Gruss,
Thomas
--
http://kaiser-edv.de/news/
Hier eine kleine Anleitung hinsichtlich Bedeutung der auszufüllenden Formularfelder.
