Hallo!

Ich versuche gerade verzweifelt unter Java eine Datei auf einem HFS+-Datenträger zu kopieren und dabei ihr FileType und -Creator zu bewahren.

Z.B. ist ja für PDFs - falls man nichts verändert hat - Vorschau die Standardapp mit der die Datei nach Doppelklick im Finder geöffnet wird. Wenn ich dies im Finder im Infodialog beispielsweise auf den Adobe Reader ändere, dann ändert sich auch der FileType.

Nun war ich der Ansicht, dass ich mittels der Apple Extensions zu Java diese Daten ermitteln bzw. setzen kann. Ich habe das mit "com.apple.eio.FileManager.getFileType(sourceFile)" bzw. "com.apple.eio.FileManager.getFileCreator(sourceFile)" und den entsprechenden Pendants eben mal implementiert.

Das Kopieren und auch das Ermitteln und Setzen der Daten funktioniert, aber im Finder sieht man für die kopierte Datei nur das Icon für die "Standardapp" anstelle des Icons der manuell spezifizierten App.

Woran kann das liegen?

hmm,

kopiere doch mal die Datei in einen Ordner und lösche danach dort die .DS Store Datei, was macht er dann?

Es gibt weder in der Quelle noch im Ziel eine .DS_Store-Datei (Listenansicht im Finder).

Soweit mir bekannt ist, sind diese Informationen aber auch an die eigentliche Datei geheftet und liegen nicht in der .DS_Store-Datei. In dieser Datei werden vom Finder meines Wissens nach auch nur Infos bezgl. Position und Größe der Icons im Fenster, ein evtl. Hintergrundbild, Position und Größe des Fensters selber etc. gespeichert.

Sonst noch eine Idee?

Der Finder bekommt nach einer File-Operation mitgeteilt welche Zuordnungen zu dem Dateityp existieren und welches Icon zu verwenden ist. Das setzten von Type und Creator sind aber üblicherweise keine File-Operationen die das auslösen, und daher wird das Icon nicht geupdatet.

Evtl. hilft aber schon ein einfaches "touch" auf die Datei um das update auszulösen, oder ein Suffix an den Namen zu hängen.

Hilft das nicht, schau Dir mal die Launch Services an. Das ganze läuft darüber.

Das hängt von der Mac OS X-Version ab. Unter Mac OS X Leopard wird das Icon spätestens nach Anklicken des Finder-Fensters sofort geändert.

Möglicherweise ist das einfach nur falsch programmiert? Welche Type/Creator-Codes wurden denn verwendet?

iCode: Ich bin mir nicht sicher, ob Du das Problem so siehst wie ich. Vielleicht habe ich mich auch etwas unklar ausgedrückt.

Stelle Dir folgende Situation vor: Du erstellst irgendein Dokument unter NeoOffice Writer und speicherst es ab. Nehmen wir an NeoOffice ist die Standardapp für ODT-Dateien. Also trägt die eben erstellte Datei auch ein entsprechendes NeoOffice-Icon. Im Finder ändere ich jetzt die Standardapp ("Preferred Application for a Document" laut der Dokumentation deren URL Du freundlicherweise herausgesucht hast) auf OpenOffice.org. Das Dokument bekommt jetzt im Finder das passende Icon von OpenOffice.org verpasst.

Nun kommt das entscheidende: Die Datei wird per Java an einen anderen Ort kopiert. Anschließend wird das Icon bzw. die "Preferred Application" überprüft und siehe da: Die kopierte Datei hat als Standardapp NeoOffice und nicht OpenOffice.org wie die Quelldatei.

Hat man aus Java heraus mit Boardmitteln überhaupt die Möglichkeit die Preferred App einer (Dokument-)datei zu beeinflussen? Gibt es da eine kurze, elegante Lösung?

Ja, das dürfte - wie Du schon richtig erkannst hast - daran liegen, dass die erweiterten Finder-Attribute der Datei nicht mitkopiert wurden. Das Kopieren von Type- und Creator-Code müsste da helfen. Wie schon gesagt ist möglicherweise wirklich nur ein kleiner Fehler im Deinem Programm?

Es sind vier Aspekte, die bei der Berechnung der "preferred app" eine Rolle spielen:
- Der Creator-Code der Datei.
- Der Type-Code der Datei.
- Die Endung des Dateinamens.
- Die Präferenzen des gegenwärtigen Benutzers in seiner persönlichen LaunchServices-Datenbank.

Die Änderung des Dateinamens geht immer. Type und Creator kannst Du mit den schon erwähnten com.apple.eio.FileManager-Funktionen setzen. Auf die LaunchServices-Einstellungen hättest Du allerdings nur über die Systemfunktion LSSetDefaultRoleHandlerForContentType() Zugriff. Dafür steht meines Wissens kein Java-Bridging zur Verfügung.

Um auf Dein ursprüngliches Beispiel zurückzukommen: Der Type-Code für eine Datei, die mit Acrobat-Reader geöffnet werden soll, wäre 1346651680 (entspricht 'PDF ') und der Creator-Code wäre 1128354383 (entspricht 'CARO'). Hast Du das so ausprobiert?

Also nach einigem Probieren und Überprüfen bietet sich mir ein sehr inkonsistentes Bild:

Ich habe einige ODT-, ODS- und PDF-Dateien kopieren lassen. Die preferred apps sind jeweils OpenOffice.org, Adobe Reader bzw. Vorschau. Die Creators sind für die ODT- bzw. ODS-Dateien anstelle von OpenOffice.org NeoOffice. FileType- und -Creator-Code sind für die ODS 0 und 0, für die ODT 1313809734 und 0, für die beiden PDFs 0 und 0.

Was können wir daraus lernen?

Das Lesen und Setzen von Type- und Creator-Code funktioniert in meinem Programm, aber es hat nicht den gewünschten Effekt. Sind diese Methoden von Apple möglichweise fehlerhaft implementiert worden (finde ich unwahrscheinlich) oder holt sich der Finder diese Angaben doch eher aus der LaunchServices-Datenbank des aktuell angemeldeten Users?

Um letzteres zu prüfen, habe ich per Finder die besagten Dateien mal in den Ordner /Users/Shared kopiert und mich mit einen anderen Account am Rechner angemeldet: Die Preferred-Apps blieben erhalten!

Wie geht der Finder vor und wie kriege ich das nur unter Java hin?

Dann werden Creator-Codes, die für eine erzwungene Bindung an ein Programm sorgen, in Deinen Beispielen überhaupt nicht benutzt. Nur die ODT-Datei hat einen Type-Code, nämlich 'NO%F'. In allen anderen Fällen ist also die Dateiendung ausschlaggebend.

Die LaunchServices-Datenbank enthält keine Informationen über Dateien. Sie enthält nur die Informationen, welche Type-Codes und welche Dateiendungen der jeweilige Benutzer momentan an welches Programm geknüpft hat.

Der Finder kopiert alle erweiterten Attribute einer Datei. Dazu gehören auch die Typcodes.

Ich wiederhole nochmal die Frage: Wenn Du Type/Creator auf 1346651680/1128354383 setzt, kannst Du dann die Werte auch korrekt zurücklesen?

Nicht wirklich, der ODT/ODS-Creator war NeoOffice. Für den Test habe ich die preferred app auf OO.o geändert. Trotzdem blieben FileType und FileCreator unangetastet...

Ich habe diese Werte eben auf eine PDF-Datei angewandt, die vorher die Werte 0 und 0 hatte => Es hat funktioniert! Wie komme ich nun an diese Werte? Dann wäre mein Problem gelöst...

Ich fürchte, wir reden aneinander vorbei. Du hast doch gesagt, dass der Creator-Code 0 war. Der Wert 0 heißt, das kein Creator gesetzt ist. Das ist der Normalfall, denn das Setzen eines Creator-Codes gilt heute als benutzerunfreundlich oder sogar als "böswillig". Beim Anlegen von neuen Dateien sollten Programme keine Creator-Codes setzen, denn dann hat der Benutzer zunächst keine Wahl mehr, mit welchem Programm er ein Dokument öffnen kann.

Stattdessen wird im Normalfall nur eine Dateiendung und/oder ein Type-Code gesetzt. Das führt dazu, dass die Launch-Präferenzen des Benutzers beachtet werden können.

Was soll "OO.o" sein? Wahrscheinlich hast nur Deine persönliche Benutzerpräferenz für das Öffnen von Dateien mit der Endung ".odt" auf Open Office umgestellt. Die Type-/Creator-Codes bleiben dann selbstverständlich leer.

Beim Kopieren einer Datei liest Du Type- und Creator-Codes vom Original und schreibst Type- und Creator-Code wieder zur Kopie.

OK, habe ich ja verstanden, aber ...

... warum soll das so sein?

Das ist es ja was ich die ganze Zeit versuche klar zu machen. Ein eben erstelltes NeoOffice-Dokument hat Type 0 und Creator 0, dieselbe Datei hat nach Umstellung der Preferred App auf OpenOffice.org dieselben Werte, das Finder-Icon (und noch mehr) hat sich aber entsprechend der Anwendung verändert.

Nun nochmals meine Frage: Woher weiß der Finder, dass diese Datei fortan nicht mehr mit NeoOffice sondern mit OpenOffice.org zu öffnen ist, wenn doch die Werte für Type und Creator nicht verändert wurden und wie bekomme ich es unter Java hin.

Wenn ich explizite Werte für FileType und -Creator einer Datei aufpräge, dann ist es ja nicht das Problem, denn das funktioniert ja. Aber wo bekomme ich die richtigen Werte her, wenn sie nicht in der Quelldatei zu finden sind?

Jetzt verstehe ich, was Du meinst.

In diesem Fall scheint der Finder eine andere, undokumentierte Art und Weise zu benutzen, die Datei fest an eine Applikation zu binden. Das ist wohl deshalb eingeführt worden, weil moderne Programme meistens keine Creator-Codes mehr haben.

Der Finder legt in diesem Fall einen Datei-Fork mit der Kennung "rsrc" (Resource Fork) an. Dort hinein wird zum einen eine "Custom Icon Resource" geschrieben, zum anderen eine Resource für ein "Application Binding Override".

Die Lösung ist, auch den Resource Fork mitzukopieren. Von Java aus kannst den Resource Fork einer Datei mit dem Namen "Beispiel" wie eine zweite Datei (also mit den üblichen Dateifunktionen) ansprechen, indem Du an den Dateinamen den Pfad "/..namedfork/rsrc" anhängst.

Also: Nicht nur die Datei "Beispiel" kopieren, sondern auch die Datei "Beispiel/..namedfork/rsrc", falls sie existiert.

Ja, super! Das war ein Volltreffer!!

Vielen Dank, dass Du so hartnäckig drangeblieben bist!

Jetzt ist mein Programm auch endlich in der Lage Mac-Dateien korrekt zu kopieren.

Alles funktioniert bestens, nur eine Kleinigkeit ist mir noch aufgefallen: Die Preferred App der beiden mit NeoOffice erzeugten ODT- bzw. ODS-Dateien habe ich vor der Kopie auf OpenOffice.org umgestellt. In der Kopie kommt diese Information dank Deines Tipps auch endlich an, nur das Icon ist ein leeres Blatt. Es hilft auch nichts ein, zwei Mal drauf zu klicken oder das Finder-Fenster zu schließen und wieder zu öffnen. Es bleibt leer. Andere Icons sind bislang nicht betroffen. Auch nicht die von NeoOffice. Die Dateien werden jedoch korrekt nach Doppelklick mit OpenOffice.org geöffnet.

Eine Ahnung woran das noch liegen kann?