Wie erkennt MacOSX mit welchem Programm die Datei bearbeitet wurde?

[alabamasun]

Hallo an alle, mal eine kurze Frage...

Wie erkennt MacOSX mit welchem Programm die Datei bearbeitet wurde und zeigt einem das im System auch als Symbol an!!!!?

Ich meine Damit zB. man läd eine JPG Datei aus dem Netz dann will er die noch mit dem internen Vorschau Programm öffnen, aber wenn man diese Datei mit irgendeinem Programm bearbeitet (zB Photoshop), dann sieht man an der Datei das diese mit diesem Programm bearbeitet wurde (bei unserem Photobeispiel würde die JPG Datei dann ein Photoshop Layout Logo im System haben).

Wenn man zB eine PDF Datei aus dem Netz hat wird sie mit dem Mac Vorschau Client geöffnet sobald man zB eine eigene Datei mit Adobe Prog erstellt sieht man das man am Logo das man es damit bearbeitet haben muss.

So kann man die Beispiele beliebig weiter spinnen, wie funktioniert dieses? Merkt sich MacOSX das einfach oder wird zB in der JPG eine Kennzeichnung eingebettet damit jedes MacOSX oder auch PCs dieses auslesen können oder wie geht diese Technik!?

Danke für eure Aufklärung und Hilfe, für diese vielleicht dumme Frage.

 

[Dadelu]

Ich bin mir nicht ganz sicher, aber ich denke, os hat intern eine "Auflistung" aller Formate die es kennt.. Dazu verknüpft sind die Programme, welche die spezifische Datei bearbeiten können.. Daher wird beim CNTRL- Klick auf eine Datei, auch verschiedene Progs vorgeschlagen mit denen man die Datei bearbeiten kann...

Jedoch müsste ein neu installiertes Programme (zum Beispiel Photoshop) os melden, dass es "vorhanden ist auf dem Rechner und es selber auch jpg etc. bearbeiten kann".. Dadurch wird dies im System erfasst und bei einem weiteren Klick auf die Datei, wird die Möglichkeit geboten, sie mit diesem Programm zu bearbeiten...

Gruss

 

[mullzk]

os x hat (als erbe von macOS classic) zu jeder datei auch einen ressource-fork. wenn du mal was auf einen Windows-USB-Stick oder ein Netzlaufwerk abspeicherst, sind das die nervigen ._ dateien, im HFS sind die völlig transparent.

im ressource fork steht unter anderem der creater code (von welchem programm das file erstellt wurde) sowie der weissnichtmehrwieerheisst code, mit welchem programm das file geöffnet werden soll.

fehlt bei einem file der ressource fork, wird er gemäss file-erweiterung geöffnet...


soll aber in ferner zukunft endlich besser werden....

 

[.holger]

also in den meisten dateien steht sogar drin mit welchem Programm es bearbeitet wurde.... (es gab mal einen Fall da hat einer eine wav Datei mit einem Windowssound angeguckt und festgestellt, dass das Programm mit dem es bearbeitet wurde auf den Namen einer Hackergruppe registriert war...)

 

[mullzk]

nein, sollte man IMHO nicht.

nicht nur gibt es jede menge carbon-apps, die immer noch mit ressource forks arbeiten, vor allem haben die ressource forks im finder nach wie vor die höchste wertigkeit. solange eine datei ressource forks hat, wird der finder die dateierweiterung ignorieren. und solange dies der fall ist, bleibt dieses konzept auch unter tiger sehr wichtig...

ganz abgesehen davon, dass im vergleich zu den dateierweiterungen ressource forks ein geniales konzept sind....


abhilfe wird ja vermutlich UTI schaffen, aber in tiger weiss der finder noch nichts davon. aber das gehört zu jenen dingen, wo ich mir von 10.5 wirklich etwas verspreche. aber auch dann werden die ressource forks nicht von einem auf den anderen tag ausgestorben sein...


ausserdem bezog sich die frage ja auf einen mechanismus wie er gegenwärtig nur mit ressource forks entstehen kann....

 

[tjp]

ganz abgesehen davon, dass im vergleich zu den dateierweiterungen ressource forks ein geniales konzept sind....

Es gibt da nur ein Problem, Type&Creator haben bloß nichts mit Resource Forks zu tun. HFS(+) hat eine Erweiterung des Dateiheaders in dem stehen Type&Creator.

Es spräche also nichts dagegen ein UFS mit Type&Creator zu schreiben und in MacOS X zu implementieren. Das könnte dann bloß keine ResourceForks, die ich für ein einziges Ärgernis halte.

Es ist jedenfalls sinnvoll, den Typ einer Datei in der Datei selbst zu kodieren, weil so bei einem Verschicken der Datei sichergestellt ist, daß diese Information nicht verloren geht. Es gibt dazu zur Zeit mehrere Möglichkeiten.

Die Datei wird per MIME Kodierung, üblicherweise per Web oder Mail, verschickt. Hier wird ein MIME Metainformation zum eigentlichen Dateiinhalt dazu gepackt. Je nach der Konfiguration auf dem Zielcomputer wird zu dem betreffenden MIME Type ein Programm und Type zugeordnet. Die Andere Möglichkeit besteht darin, daß man XML nimmt. Hier wird die Metainformation zusammen mit dem eigentlichem Dateiinhalt in eine flache Datei geschrieben. Aus den Metainformatione kann man dann ähnlich wie bei MIME die betreffende Pogrammzuordnung benutzen oder falls vorhanden den exakten Type&Creator benutzen. (Das ist Apples Favorit für die Zukunft)

Daneben gibt es die Möglichkeit HFS+ Dateien via Image/StuffIt in der Welt zu verschicken. Hier werden die Dateien nach dem Dekodieren so behandelt, als ob sie auf einem HFS+ Medium durch die Welt geschickt würden.

So toll HFS+ aus der Sicht vieler Anwender ist, so hat es doch erhebliche Schwächen, die es sehr sinnvoll erscheinen lassen es durch andere Lösungen zu ersetzen.

Ich versuche mal aus dem Gedächtnis zu rekapitulieren was das alles ist.

• "Locale" Problem HFS+ hat die Sortierreihenfolge von Dateinamen nicht wie bei UNIX üblich in ein Locale kodiert, sondern in den Treiber von HFS+. D.h. die Sortierreihenfolge ist abhängig davon was für Filesystem man benutzt. Mit HFS+ hat man die traditionelle Sortiereihenfolge mit allen anderen die UNIX übliche. Es spräche nichts dagegen einfach ein Mac Locale für UNIX zu schreiben, und man hätte dieselbe Sortierreihenfolge für alle FS.
• Desktop DB Die DB Datei ist leider ein Flaschenhals, der Operationen auf dem Filesystem verlangsamt. Es wird für DBMS schon lange kein Dateisharing mehr genutzt, sondern eigene DBMS Server. Hier sollte Apple eine adäquaten Ersatz finden.
• Sicherheitsprobleme MacOS X ist zusammen mit HFS+ case insensitiv. Das Problem dabei UNIX Applikationen erfordern case sensitive FS (sieh apache Exploit). Der Witz an der Sache HFS+ kann das nur der betreffende Treiber von Apple verhindert das. Wenn Apple das von ihnen gewünschte Verhalten aus dem HFS+ Treiber raus in die Carbon bzw. Cocoa FrameWorks verlangern würde, wäre das Problem elegant gelöst. Statt wie bisher potentielle Exploits zuzulassen, gäbe es im Zweifelsfall unterschiedliche Dateinamen. Aber nur dann wenn jemand UNIX Apps nutzen würde. Für den "normalen" Nutzer würde sich nur in Konfliktfällen etwas ändern. Für alle Dateien, die über Carbon/Cocoa Applikationen geschrieben, verändert etc. würden, gäbe es das Problem gar nicht.
• Sicherheitsrisiken durch Mac Toolbox Dateizugriffshandler vs. UNIX FS Handles. Das ist hauptsächlich ein Problem von Carbon und Classic. Letzteres wird mit dem x86 Switch entsorgt.
• Performance HFS+ ist nachweislich langsam. Es wäre für Apple mal an der Zeit ein bessere FS für MacOS X einzuführen.
• RealTime Unterstützung IRIX XFS hat seit Jahren Unterstützung für RealTime Anwendungen. Das heißt, daß das FS garantierte Durchsatzraten bietet. Die ganzen Multimedia Anwendungen profitieren enorm von so einem Feature.
• Cluster Größe Leider verwaltet HFS+ die Datein auf der Platte nicht sonderlich effizient. Es gibt das deutlich bessere FS siehe IRIX XFS, AIX JFS oder SUNs neues ZFS.
• keinerlei LVM Fähigkeit Wer schon einmal eine volle Platte hatte, der er nicht umkopieren konnte/wollte, weiß LVM zu schätzen. Für alle Arten von Software/Hardware RAIDs mittlerweile sind LVMs unerläßlich.

 

[mullzk]

danke für diese ausführungen, habe gerade wieder mal ein stück was gelernt... drei fragen habe ich dennoch:
- war type und creator denn früher in den ressource forks drin, oder wie komme ich auf diese assoziation?
- was ist denn heute noch in den ressource forks drin?
- wie geht das mit dem dateiheader, in dem type und creator drin sind? ist das ein integraler bestandteil eines files und wenn ja, wie gehen dann andere betriebssysteme, die type und creator nicht kennen, damit um?

 

[tjp]

danke für diese ausführungen, habe gerade wieder mal ein stück was gelernt... drei fragen habe ich dennoch:
- war type und creator denn früher in den ressource forks drin, oder wie komme ich auf diese assoziation?
- was ist denn heute noch in den ressource forks drin?
- wie geht das mit dem dateiheader, in dem type und creator drin sind? ist das ein integraler bestandteil eines files und wenn ja, wie gehen dann andere betriebssysteme, die type und creator nicht kennen, damit um?

Selbst mit dem alten Apple HFS (HP-UX hat übrigens auch ein HFS) war Type&Creator im Header der Datei, es gehörte zu den Metainformationen des FS. Wie das früher mit dem MFS aussah weiß ich nicht, da ich damals noch keinen Mac hatte. Aber das war es wohl ähnlich.

UNIX definiert nur einen recht minimalen Satz an Funktionalität, die das OS an Metainformationen vorhalten muß. Aber viele Anbieter haben das erweitert, die verbreiteste Erweiterung dürften ACLs sein.

Wenn man Metainformationen von einem Computer auf einen anderen Computer übertragen will, dann muß das Protokoll bzw. das Archivformat dies unterstützen. Das gilt für UNIX genauso wie für MacOS in seiner klassischen Form. tar macht auch nichts anderes als die UNIX typischen Metainformationen mit zu archivieren.

Z.B. Wenn Du eine Datei mit ACLs auf ein FS kopierst, daß dies nicht unterstützt sind die ACLs weg. Ditto verhält es sich mit einem tar, welches dies nicht kann.

Nichtsdestoweniger könnte Apple ein bestehendes FS um die Funktionalität Type&Creator erweitern. Die speziellen APIs sind eh schon vorhanden, man müßte nur eine Binding für das neue FS einbauen. Allerdings würde man keinen Vorteil beim Datenaustausch haben, gegenüber dem status quo, da die alten Probleme erhalten blieben. Man sollte Type&Creator nicht überbewerten, früher war das mal ein tolles Features. Heute im Zeiten des Internets und bei der geringen Verbreitung des Macs ist das eine Insellösung, die die Bearbeitung nur lokal erleichtert.

Daher erscheint es mir wichtiger eine Lösung zu finden bei der Type&Creator innerhalb einer flachen Datei enthalten sind. Und das natürlich in einer portablen Form, so daß man das auch unter Windows nutzen kann. Apple kann viel in MacOS X einbauen, wenn niemand unter Windows diese Funktionalität nutzt wird nichts draus. Am wahrscheinlichsten ist es, daß sich in absehbarer Zeit XML durchsetzen könnte. Bleibt nur zu hoffen, daß die Dateien so aufgebaut sind, daß die notwendigen Informationen dort mit abgelegt werden.

Richtig genutzt wurden die ResourceForks nur von Applikationen, einige Programme haben in die ResourceForks der Dateien auch Metainformationen abgelegt, z.B. an welcher Stelle der Cursor bei einem Texteditor sich befand o.ä. Aber das ganze war und ist eher eine Sache der Applikationen. Die meisten Dateien sind flach.

Insofern konnte ich nie so recht die Begeisterung für die Forks verstehen. Der aktuelle Stand ist es, daß Cocoa Programme zwar als ein Icon auf dem Finder erscheinen, in Wahrheit aber ein Verzeichnis sind mit der Endung ".app", den der Finder nur als Einheit darstellt. Wenn man diese "eine Datei" per Drag&Drop durch die Gegend kopiert, dann kopiert der Finder rekursiv immer gleich den ganzen Ordner. Funktioniert auch und den meisten Mac Nutzer dürfte nicht klar sein, wo der Unterschied liegt.

Bei Carbon Programme hängt es davon ab, wie sie aufgebaut sind. Und für welche Plattform sie bestimmt sind, ich habe hier PEF Binaries mit ResourceForks und welche als ".app" Verzeichnis. Bei den MachO bin ich mir nicht sicher, da müßte ich auch erstmal nachsehen.

 

[pepi]

MFS: Macintosh File System
Nur für Disketten, seinerzeit. 3.5" 400kB (Single Side/Double Density), später dann mit 800kB (Double Side/Double Density) jeweils 80 Spuren zu je 10 Sektoren.

Mit Einführung von System 3 (Macintosh System Software 0.7) wurde erstmals das HFS eingeführt und war damals ausschließlich Festplatten vorbehalten. Das
Hierarchical File System ermöglichte es erstmals Dateien in Ordnern (und Unterordnern) zu gruppieren.

Mit der Einführung des SuperDrive (Double Side/High Density) Disketten Laufwerkes wurde erstmals HFS auch für Disketten verwendbar. Sagenhaft 1.44MB pro Medium konnte man auf so einem Ding Unterbringen. (Das SuperDrive war damals eine Built-to-Order Option für zB den Macintosh SE/30 oder den Macintosh IIfx) Ich bilde mir ein, daß es mit System 7.1 oder so auch die Möglichkeit gab 800kB Disketten HFS zu formatieren, aber da ist meine Erinnerung schon etwas verblasst. Bis 7.5.5 (Rev 2) ging das noch, danach nur noch HFS für HD Disketten. (High Density, nicht High Definition)

Mit Mac OS 8.1 wurde das erweiterte HFS+ Oder "Mac OS Extended Format" eingeführt. Dies ermöglichte durch kleinere Clustergrößen eine wesentlich besser Nutzung der unglaublich großen 320MB und 500MB Festplatten. Von HFS+ Formatierten Partitionen/Festplatten konnten jedoch nur noch Macs mit PowerPC Prozessor starten. 68k Macs mußten als Startvolume weiterhin auf das bewährte HFS zurückgreifen. Die berühmte SimpleText Datei "Where have all my files gone" war damals in aller Munde und auch heute noch auf jedem HFS+ Wrapper Volume vorhanden.

Die nächste große Erweitung zu HFS kam mit Mac OS X Server 10.2. Dort wurde erstmals offiziell journaling unterstützt. Unter der Client Version von Jaguar konnte man dies aber ebenfalls schon einschalten. Seit Mac OS X 10.3 Panther ist jHFS+ das Standard Format.

Mit Mac OS X !0.4 Tiger gesellte sich erstmals auch eine Case-sensitive Version von HFS zum bunten Treiben der Formate. (Ich glaube in Panther war das zumindest inoffiziell auch schon möglich.) Bisher wird davon jedoch noch wenig Gebrauch gemacht und so manche Applikation hat auch so Ihre liebe Not damit. Speziell ältere (oder auch ein paar neuere) Carbon Applikationen leiden.

Zu beachten ist, daß HFS immer Case-aware war. Also zur unterscheidung von Dateinamen zwar nicht zwischen "Mac" und "MAC" als zwei unterschiedliche Dateien unterschieden hat. Zur Namensgebung waren große und kleine Buchstaben jedoch immer schon möglich und wurden auch korrekt verarbeitet.

Die MS-DOS Formate FAT16 und FAT32 können bis heute nicht Unterscheiden. Bei FAT32 kommt eine Erweiterung zum Tragen die mehr als die üblichen 8.3 Notation ermöglicht.


@tjp: Danke für Deine beiden tollen und ausführlichen Postings!

@mullzk: Resource Forks finden auch heute noch Einsatz bei vielen Carbon Applikationen und Dateien. zB: .sit (welche zum Transfer übers Internet als BinHex4 .hqx oder MacBinaryIII .bin codiert werden muß), .img das DiskImage Format von Apple's DiskCopy oder Aladdin System's ShrinkWrap (heute heißt die Firma Allume Systems und ShrinkWrap wurde nie für Mac OS X portiert), Vorschauinformationen in Bilder werden heute noch von zB GraphicConverter oder Photoshop als ResourceForks angelegt.

Der Trend geht im Filesystem jedoch weg von echten Forks (da diese bei vielen anderen Filesystemen nicht unterstützt werden oder Kunstgriffe zur Abbildung benötigen. ._Dateien)
Wie die Cocoa Frameworks konkret NamedForks im FileSystem abbilden weis ich leider nicht genau.

Gruß Pepi
PS: ResEdit Rules!

 

[tjp]

Mein IIcx streikt, sonst würde ich mal wieder 6.0.x starten. Unter System 7.1.2P was bei meinem erstem Mac dabei war, kann ich mich nur an HFS, ProDOS und DOS Disketten Formate erinnern, egal ob DD oder HD Disketten. Die einzige Besonderheit der DD Disketten war ihre GCR Kodierung (was nur Mac Floppy Drives konnten), im Gegensatz zum MFM Kodierung der HD Disketten.

 

[pepi]

GCR (Group Codeed Recording) war damals in der Tat eine Besonderheit des Mac. Der Commodore Amiga verwendete ebenfalls dieses Verfahren, weshalb diese beiden Systeme auf einer DD Diskette auch nominale 800kB unterbrachten und nicht "nur" 720kB wie die MFM (Modified Frequency Modulation) verwendenden Kollegen aus der DOS und Atari Welt. MFM wurde für SD, DD und HD Disketten verwendet.
Der Disketten Controller des Atari ST konnte mit spezieller Software (Namens EXChanger) diese Disketten dennoch lesen. Auch der Mac-Emulator Aladin konnte diese Disketten damals am Atari lesen. Auf "PC" Hardware war meines Wissens damals ein spezieller Floppy Controller chip erforderlich.

Umgekehrt konnten Macs schon immer die PC Formatierten Disketten lesen.

Schön wieder mal in diesen Erinnerungen zu schwelgen.
Gruß Pepi