OS X Dateien unter OS 9 öffnen

M

mindhead

Neues Mitglied
Thread Starter
Dabei seit
12.04.2005
Beiträge
7
Reaktionspunkte
0
Moin,

folgendes Problem liegt vor:
Wir haben ein Mac-Server mit OSX auf dem OSX-Dateien (z.B. Word) direkt gespeichert werden (d.h. direkt auf dem Server-Laufwerk gespeichert).
Nun können die OS 9-Clients gut drauf zugreifen, sehen aber die Resource-Forks der OSX-Dateien (also die ._ dateien). Die OS 9 Clients können die Dateien nicht durch einen Doppelklick öffnen und auch drag&drop auf das programm-icon geht nicht.
Dass die resource-forks von den beiden Systemen nicht kompatibel sind, weiss ich auch schon.
Gibts vielleicht trotzdem eine Lösung? (Ausser starten des Programms und öffnen der datei mit datei/öffnen?)

Danke für Hinweise.

Falko
 
Warum habt ihr denn das Server-Laufwerk nicht in HFS+ formatiert?
 
Das Laufwerk ist als HFS+ formatiert.
 
Nee, ist es nicht. Wenn es HFS+-formatiert wäre, dann würde man keine ._Dateien sehen. Die gibt es nämlich auf HFS+-formatierten Volumes nicht (bzw. werden die Resourcen dort, wie es sich gehört im Resourcenzweig gespeichert).
 
Wenn die Info über das Laufwerk sagt, dass es ein MacOS Extended (journaled) Format ist, dann ist es nicht als HFS+ formatiert?

Es ist laut System-Profiler definitiv als HFS+ formatiert...
 
Zuletzt bearbeitet:
Dann frage ich mich (bzw. Dich), wie es zu den ._-Dateien kommt.
 
Gute Frage..
das kann ich dir auch nicht beantworten.

Werden die ._-Dateien nicht immer von OS X geschrieben? so wie os 9 die finder.dat und resource.dat geschrieben hat?
 
Von OS 9 aus sieht man immer diese ._-Dateien... ...selbst bei unter OS X gebrannten
CDs.
 
Wie verbinden sich denn die OSX-Clients zum OSX-Server?

Eigentlich kann das nur passieren wenn sich die Clients über SMB, HTTP (WebDAV) oder NFS verbinden. Wenn sich die OSX-Clients genauso wie die OS9-Clients auch über AFP mit dem OSX-Server verbinden, dann gibt es solche Probleme auch nicht.

Difool schrieb:
Von OS 9 aus sieht man immer diese ._-Dateien... ...selbst bei unter OS X gebrannten
CDs.
Zum Vergrößern anklicken....
Das gilt aber nicht für das angesprochene Problem. Das gilt noch nicht einmal unbedingt für CDs. Ich sage nur: "Mac OS CD" oder "Mac OS Erweitert CD".

Pingu
 
Pingu schrieb:
Das gilt aber nicht für das angesprochene Problem. Das gilt noch nicht einmal unbedingt für CDs. Ich sage nur: "Mac OS CD" oder "Mac OS Erweitert CD".
Zum Vergrößern anklicken....
Das mag sein. Bisher hab ich die Dateien immer dabei gehabt, wenn ich OSX-CDs
bekommen habe.
 
mindhead schrieb:
Werden die ._-Dateien nicht immer von OS X geschrieben? so wie os 9 die finder.dat und resource.dat geschrieben hat?
Zum Vergrößern anklicken....
Das gilt nur für Volumes, die nicht in HFS / HFS+ formatiert sind. Auf HFS /HFS+-Volumes werden die Resourcen in den Resourcenzweig geschrieben und die Metadaten ins Dateisystem. Unter Mac OS genauso, wie unter Mac OS X.

@ Pingu
Wenn sich die Clients über SMB verbinden und auf ein HFS+-Volume schreiben, werden gar keine Resourcen geschrieben, die gehen einfach verloren (SMB weiß nichts von Resourcen und bricht die Datenübertrageung am Ende des Datenzweiges ab, Mac OS X aber sieht ein HFS-Volume am anderen Ende und teilt die Daten und Resourcen nicht auf. SMB und HFS+ machen zusammen aber auch keinen Sinn). Bei anderen Formaten werden die ._Dateien angelegt.

@ Difool
Derjenige, von dem Du die CDs bekommst, brennt diese offensichtlich fälschlicherweise als reine ISO. Normalerweise sind CDs aus Mac OS X (also im Finder gebrannt) ISO/HFS-hybrid. Die HFS Seite sieht aus, wie immer, auf der ISO-Seite sieht man AFAIK gar keine Resourcen.
 
Zuletzt bearbeitet von einem Moderator:
._ut schrieb:
@ Pingu
Wenn sich die Clients über SMB verbinden und auf ein HFS+-Volume schreiben, werden gar keine Resourcen geschrieben, die gehen einfach verloren (SMB weiß nichts von Resourcen und bricht die Datenübertrageung am Ende des Datenzweiges ab, Mac OS X aber sieht ein HFS-Volume am anderen Ende und teilt die Daten und Resourcen nicht auf. SMB und HFS+ machen zusammen aber auch keinen Sinn). Bei anderen Formaten werden die ._Dateien angelegt.
Zum Vergrößern anklicken....
Hmm... bei mir sieht das aber anders aus.

Ich habe mich gerade mit meinem Server (Mac OS X Jaguar Server Unlimited) über SMB verbunden und eine Datei r'über geschoben. Dann habe habe ich mich über ssh verbunden und was sehe ich da? Eine Datei mit "._" genau passend für die Datei, die ich rübergeschoben habe. Bei AFP (was wir normalerweise nutzen/ich habe SMB nur für die beiden Windows-Rechner freigeschaltet) passiert das nicht. Übrigens die Platten sind mit HFS+ formatiert.

Pingu
 
Pingu schrieb:
Hmm... bei mir sieht das aber anders aus.

Ich habe mich gerade mit meinem Server (Mac OS X Jaguar Server Unlimited) über SMB verbunden und eine Datei r'über geschoben. Dann habe habe ich mich über ssh verbunden und was sehe ich da? Eine Datei mit "._" genau passend für die Datei, die ich rübergeschoben habe.
Zum Vergrößern anklicken....
Du hast recht. Ich hatte bei meinem Versuch (kopieren eines TextClippings über SMB auf die eigene Festplatte) vergessen, dass die ._-Datei im Finder ja unsichtbar ist und hatte nur die 0KB große Datendatei des kopierten Textclippings gesehen, welche sich beim Öffnen per Doppelklick auch leer zeigte.

Das bedeutet aber auch, dass die Datei und die ._-Datei auf einem HFS-Volume nicht zusammengefasst werden (eigentlich auch klar, die sind ja nur ein Workaround für Dateisysteme, die keine Resourcen können). Wie mindhead es am Anfang dieses Threads beschreibt. Die beschriebenen ._-Dateien sind also offensichtlich entstanden, weil die Verbindung zum Mac OS X-Rechner nicht über AFP erfolgt ist, sondern z.B. über SMB, NFS o.ä..

Um die Daten und Resourcen dann wieder zusammenzuführen, müsstest Du, mindhead, die Dateien und die ._Dateien auf ein FAT-Volume kopieren und dann wieder unter Mac OS X auf das HFS-Volume zurück-kopieren. Dann sind sie auch unter Mac OS 9 wieder richtig. (Und natürlich überprüfen, warum die Dateien nicht über AFP auf dem Server übertragen worden sind.)
 
Zuletzt bearbeitet von einem Moderator:
Also, vielen Dank erstmal für die Infos.

die OSX-Clients sind per afp angebunden, aber..

Folgendes habe ich rausgefunden:
Ein X-Client erstellt z.B. eine txt-Datei in Text-Edit und speichert diese auf dem Server-Laufwerk ab.
Es wird eine ._-Datei erstellt.
Wird aber die text-Datei auf dem Client gespeichert und dann per Finder übertragen, so wird keine ._Datei angelegt.
Das direkte Speichern auf dem Server ist bei uns aber normal, da auch Dateien vom Server direkt geöffnet und gespeichert werden. Es wird dann immer eine ._-Datei erzeugt.
Und das gilt auch für Programme, die nicht aus der Classic-Umgebung heraus die Datei auf dem Server speichern.
Enstsprechend müssten die Programme die Dateien nicht per afp auf dem Server ablegen. Ist darüber was bekannt?

OK, ich werde das mit dem FAT-Laufwerk mal testen.
 
Dass beim direkten Speichern auf den Server ._-Dateien erzeugt werden, ist aber nicht normal.

Was sind das für Programme, die nicht aus der Classic-Umgebung heraus die Datei auf dem Server speichern? Normalerweise sollte das Programm in der Classic-Umgebung überhaupt nicht mitbekommen, dass es sich bei dem Volume um ein Netzwerk-Volume handelt. Das Volume wird den Classic-Programmen von Mac OS X angeboten als wäre es ein lokales Volumes.
 
Unter der Classic-Umgebung ist dies hauptsächlich ist das Office-98-Paket.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten