Soweit ich das im Kopf habe, sieht ein Zellenverweis in eine andere Mappe so aus:
Mappenname!A1

Servus.

Eine neue Frage an die Excel-Spezialisten unter Euch:
Ich möchte ein Teilergebnis von von einer Mappe auf eine andere verweisen. Wie geht das? 

Puh, was hinter einer kleinen Frage doch stecken kann.
Also, jetzt habe ich es kapiert. Danke an alle Beteiligten.
Schön mal zu wissen, was eigentlich was ist. Meta oder nicht. Fork oder nicht. Met a fork and forked a meta.

Das wird ja ganz schön metaphysisch hier... 

Echt? Mit was für einem MIME-Type versendet Mail.app denn sowas?

Sorry, Deine Fragen hatte ich überlesen. Mail verschickt sowas als "Content-Type: application/applefile". Es gibt sogar ein RFC, nämlich RFC-1740 dafür.

Und ist das Format, das Mail.app dabei verwendet, irgendwo dokumentiert?

Ja, es wird das sogenannte "AppleDouble"-Format verwendet. Es gibt dazu eine Apple Developer Note, die allerdings so alt (16 Jahre) ist, dass sie in der aktuellen Xcode-Dokumentation nicht mehr enthalten ist. Aber man kann noch drankommen. Suche mal mit einer Suchmaschine nach "AppleSingle/AppleDouble Formats for Foreign Files".

Unter OS X steht im Ressource Fork ... Bitte ausfüllen ...

Naja, darauf könnte ich antworten: Hoffentlich nichts  Das gibt ja nur Scherereien, wie man an dieser Diskussion sieht. 

Eigentlich kümmert sich ja das Betriebssystem ja gar nicht darum, was im Resource Fork drinsteht. Es ist Sache desjenigen Programms, das eine Datei anlegt, was es in den Resource Fork schreibt. In Mac OS X selbst gibt es meines Wissens nur noch ein einziges Programm, das Resource Forks benutzt, nämlich den Finder. Und zwar in folgenden Fällen:

- Wenn man einen Alias anlegt, dann stehen die Hilfsdaten, die der Alias-Manager später braucht, um die eventuell verschobene Originaldatei wiederzufinden, im Resource Fork des Alias.
- Wenn eine Datei ein Sonder-Icon hat, dann stehen die Bilddaten dieses Icons im Resource Fork der Datei.

Fremde Programme, die Resource Forks anlegen wollen, werden von Mac OS X natürlich nicht daran gehindert. Aber das ist dann deren Problem, wozu der Fork genutzt wird.
Und der Einsatz von Resource Forks bringt in der heutigen vernetzten Welt eben einige Probleme, da sie immer mit viel Mühe (wie diesen "._"-Dateien) emuliert werden müssen, wenn sie das HFS-Dateisystem verlassen.

Das mit dem Icon ist zweiteilig: Die Information, dass ein Icon da ist, steht in den von mir angesprochenen Finder-Attributen, das Bildchen selber aber im Resource Fork. Wie hier auch schon angesprochen wurde, haben Grafikprogramme aus der "alten Welt" oft den Trick benutzt, die Vorschau einer Bilddatei in das Icon der Bilddatei zu speichern. Ist heute eigentlich nicht mehr nötig, da die Rechner schnell genug sind, die Bilddatei zu öffnen und die Vorschau "on the fly" zu berechnen. Datenformate wie JPEG haben sogar (mehrere) Möglichkeiten ein vorbereitetes Vorschaubild bereits innerhalb des "eigentlichen" Bildes - also im Datenfork - mitzubringen. Da muss dann auch nichts berechnet werden.

Die Type/Creator-Information sind nur 8 Bytes. Alleine dafür einen Resource Fork anzulegen, wäre Overkill. Das liegt deshalb woanders, nämlich in den besagten Finder-Attributen, die das HFS-System direkt zusammen mit den Dateinamen, Berechtigungen, etc. in einer sogenannten "CatalogInfo" speichert. Zu den weiteren Finder-Attributen gehören konkret die x/y-Position des Icons, ob es sich um eine Macintosh-"Sonderdatei" (Alias, Bundle, Formularblock, INIT-Resource, Systemdatei) handelt, ob die Datei versteckt oder gelockt ist, ob die File-Extension verborgen werden soll, die Etikettenfarbe (Finder-Label) und viele andere ähnliche Kleinigkeiten.

Der Kommentar zu einer Datei steht wieder ganz woanders, nämlich in den berüchtigten ".DS_Store"-Dateien. Wie das im alten Mac OS war, weiß ich nicht. Möglicherweise in einer Art "Ordner-Resource-Fork"..?

Unter Windows kann jede Datei auch neben dem normalen Datenteil noch weitere (jetzt weiß ich aktuell nicht den richtigen Namen) Streams(?) haben.

Ja richtig, auch unter Windows gibt es Forks. Das weiß nur fast keiner.  Sie heißen dort "Alternate Data Streams (ADS)".

Zitat

Ich dachte immer Type/Creator, Vorschau, Kommentar... also alles über die Datei, sozusagen meta eben.

Das sind auch nach meinem Verständnis Metadaten. Denn sie stehen nicht in der Resource Fork.

Zumindestens bei Vorschau bin ich mir sicher, daß sowas auch in der Resource Fork gespeichert werden _kann_.
Bei EPS konnte eine Bitmap-Vorschau dort gelagert werden und der GraphicConverter legt heute noch eine Vorschau dort ab, die dann systemweit von anderen Programmen genutzt werden kann. Praktisch das Gegenstück zu "Thumbs.db", die man oft sieht.

Und jetzt kommt gefährliches Halbwissen...
BTW, gibt es das nicht nur beim Mac, daß eine Datei aus verschiedenen Zweigen (Daten- und Resource-Fork) besteht. Unter Windows kann jede Datei auch neben dem normalen Datenteil noch weitere (jetzt weiß ich aktuell nicht den richtigen Namen) Streams(?) haben. Dort können auch beliebige Daten gespeichert werden, die man einer Datei bei normalen Zugriff nicht ansieht. Wird in der Praxis aber wohl hauptsächlich von Viren genutzt, weil die Virenscanner meist nur den normalen Datenteil durchsuchen.

Also, Fork vs. Metadaten:
Ich weiß (glaube zu wissen), theoretisch kann man im Resource Fork alles speichern, aber in der Regel sind es doch Metadaten, oder nicht?
Oder bin ich mal wieder auf dem Holzweg?

Tja, ist natürlich letztlich eine Frage der Definition des Begriffs "Metadaten".  Und hier müssen wir jetzt wohl philosophisch werden: 
Davon ausgehend, dass eine klassische Mac-Datei aus zwei Zweigen (Forks) bestehen kann, müssen wohl beide Zweige als Teil der Daten bezeichnet werden, welche die Datei beinhaltet.
Der Begriff Metadaten setzt sich ja aus dem griechischen (meta) und dem lateinischen (data) Wort für Information zusammen. Seine Bedeutung wird daher gemeinhin als "Daten über Daten" beschrieben. Bei der hier zur Rede stehenden Verwendung des Begriffs im Zusammenhang mit Computerdateien kann also gemeint sein: Daten über die in Dateien enthaltenen Daten oder aber Daten über Dateien.
Bei der ersten Art der Auslegung lassen sich tatsächlich Daten über andere Daten innerhalb der selben Datei ablegen. Also z.B. Informationen über die im Datenzweig enthaltenen Daten lassen sich im Ressourcenzweig ablegen. (Allerdings diente der Ressourcenzweig in der Regel eher nicht dazu. Er enthielt ganz einfach strukturierte Daten, deren Struktur auch "extern" definiert war, so dass auch externe Software (meist das OS) gewisse Operationen damit ausführen konnte, ohne dass sie wissen musste, was die Daten genau bedeuten. In gewissem Sinne kann man es vom Zweck her vielleicht als Vorgänger von XML betrachten, obwohl es ganz anders funktionierte.)

Zurück zur zweiten Auslegung (also Daten über Dateien): wenn man mit dem Begriff keine Endlosschleife bauen will, muss es sich bei dieser Auslegung um Daten handeln, die also nicht selbst Teil der Datei sind, sondern ausserhalb der Datei gespeichert werden.

Wenn ich im Zusammenhang mit Dateien von Metadaten lese, dann verstehe ich den Begriff eigentlich immer im zweiten Sinne. Ich bin also bei Deinem Gebrauch des Begriffs davon ausgegangen, dass Du ausserhalb der Datei gespeicherte Daten über die Datei meinst und habe daher widersprochen. Aber wie mbs ja schon richtigerweise eingewendet hat, war dieser Widerspruch nicht wirklich korrekt. In jenem Teil des Mails, das von Windows Mail Clients mitunter als kleinerer Klon der eigentlichen Datei dargestellt wird (eine MIME-Kapsel des Typs application/applefile), können in der Tat auch Metadaten gespeichert sein.

Hm, kommt darauf an, was Du als Metadaten ansiehst. 

Ich kenne Forks aus der "Classic-Zeit" ja nur vom Hörensagen, aber bei alten Programmen waren in den Forks - wie der Name schon andeutet - üblicherweise die "Ressourcen" gespeichert, also z.B. die Texte und Grafiken für Dialogfenster. Also all das, wozu man in Mac OS X heute die Bundle-Technik verwendet. ("Paketinhalt zeigen"...)

Bei Dokumentendateien z.B. bei Texten waren wohl so Sachen wie Layout-, Papier- und Druckeinstellungen in den Forks gespeichert. Sind das für Dich Daten oder Metadaten?