j'utilise l'émulateur Mini vMac sous System 6 pour essayer de faire
tourner de vieux softs (pas d'autre intérêt qu'archéologique...).
Par exemple Graphing Calculator, récupéré ici :
http://www.vintageapplemac.com/software/utilities/g/
Le téléchargement consiste un fichier .sit
Je le décompresse avec Stuffit Expander sur mon Mac actuel (macOS 10.12)
et j'obtiens un unique ficher "Graphing Calculator 1.2"
J'ai récupéré par ailleurs une image disque HFS vide (800K.dsk) ici :
https://www.gryphel.com/c/minivmac/extras/blanks/index.html
macOS ne gérant plus les volumes HFS en écriture depuis un bail, je
passe sous Linux pour monter l'image et copier le fichier dessus
Tout a l'air OK. Je récupère l'image sur le Mac, et la glisse sur
l'émulateur. Dans l'émulateur je peux ouvrir le disque, je vois le
fichier que j'ai mis dessus, mais je ne peux pas l'ouvrir. On dirait que
le System 6 ne comprend pas que c'est une application.
http://prntscr.com/m4mnd9
Ca me fait pareil avec d'autres applis.
Je rate sûrement une étape cruciale, mais laquelle ? (je sens
confusément que ce sont les histoires d'Apple Double et Cie...)
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
macOS ne gérant plus les volumes HFS en écriture depuis un bail, je passe sous Linux pour monter l'image et copier le fichier dessus sudo mkdir floppy sudo mount -t hfs -o loop 800K.dsk floppy sudo cp "Graphing Calculator 1.2" floppy sudo umount floppy
Je ne suis pas sûr du tout que le Linux sache copier la section de ressources du fichier, qui est indispensable sous les systèmes classiques. Je ne suis pas sûr que le système de fichiers sous Linux (ext4 ou autre) soit même capable de représenter la section de ressource du fichier. À l'époque, on utilisait surtout le Binhex (extension hqx) lorsque le fichier devait aller sur un Unix. Donc souvent, les fichiers sont .sit.hqx lorsqu'ils transitent sur Internet. Le Binhex permet de mettre la section de données et la section de ressources dans un fichier lisible par un Unix. Je pense que le mieux serait de récupérer une version de Stuffit Expander compatible avec le System 6 et de dé-binhexer et décompresser sur le vieux système directement. Il me semble néanmoins que dans les temps très anciens, on utilisait plutôt "Compact Pro" plutôt que StuffIt qui est arrivé plus tard. Julien
pehache <pehache.7@gmail.com> wrote:
macOS ne gérant plus les volumes HFS en écriture depuis un bail, je
passe sous Linux pour monter l'image et copier le fichier dessus
Je ne suis pas sûr du tout que le Linux sache copier la section de
ressources du fichier, qui est indispensable sous les systèmes
classiques. Je ne suis pas sûr que le système de fichiers sous Linux
(ext4 ou autre) soit même capable de représenter la section de ressource
du fichier. À l'époque, on utilisait surtout le Binhex (extension hqx)
lorsque le fichier devait aller sur un Unix. Donc souvent, les fichiers
sont .sit.hqx lorsqu'ils transitent sur Internet. Le Binhex permet de
mettre la section de données et la section de ressources dans un fichier
lisible par un Unix.
Je pense que le mieux serait de récupérer une version de Stuffit
Expander compatible avec le System 6 et de dé-binhexer et décompresser
sur le vieux système directement.
Il me semble néanmoins que dans les temps très anciens, on utilisait
plutôt "Compact Pro" plutôt que StuffIt qui est arrivé plus tard.
macOS ne gérant plus les volumes HFS en écriture depuis un bail, je passe sous Linux pour monter l'image et copier le fichier dessus sudo mkdir floppy sudo mount -t hfs -o loop 800K.dsk floppy sudo cp "Graphing Calculator 1.2" floppy sudo umount floppy
Je ne suis pas sûr du tout que le Linux sache copier la section de ressources du fichier, qui est indispensable sous les systèmes classiques. Je ne suis pas sûr que le système de fichiers sous Linux (ext4 ou autre) soit même capable de représenter la section de ressource du fichier. À l'époque, on utilisait surtout le Binhex (extension hqx) lorsque le fichier devait aller sur un Unix. Donc souvent, les fichiers sont .sit.hqx lorsqu'ils transitent sur Internet. Le Binhex permet de mettre la section de données et la section de ressources dans un fichier lisible par un Unix. Je pense que le mieux serait de récupérer une version de Stuffit Expander compatible avec le System 6 et de dé-binhexer et décompresser sur le vieux système directement. Il me semble néanmoins que dans les temps très anciens, on utilisait plutôt "Compact Pro" plutôt que StuffIt qui est arrivé plus tard. Julien
pehache
Le 27/01/2019 à 20:19, Julien Salort a écrit :
pehache wrote:
macOS ne gérant plus les volumes HFS en écriture depuis un bail, je passe sous Linux pour monter l'image et copier le fichier dessus sudo mkdir floppy sudo mount -t hfs -o loop 800K.dsk floppy sudo cp "Graphing Calculator 1.2" floppy sudo umount floppy
Je ne suis pas sûr du tout que le Linux sache copier la section de ressources du fichier, qui est indispensable sous les systèmes classiques. Je ne suis pas sûr que le système de fichiers sous Linux (ext4 ou autre) soit même capable de représenter la section de ressource du fichier.
Je n'ai jamais compris comment c'était géré, cette histoire de ressources... En pratique il me semblait que c'était un fichier caché associé au fichier principal, non ?
À l'époque, on utilisait surtout le Binhex (extension hqx) lorsque le fichier devait aller sur un Unix. Donc souvent, les fichiers sont .sit.hqx lorsqu'ils transitent sur Internet. Le Binhex permet de mettre la section de données et la section de ressources dans un fichier lisible par un Unix. Je pense que le mieux serait de récupérer une version de Stuffit Expander compatible avec le System 6 et de dé-binhexer et décompresser sur le vieux système directement. Il me semble néanmoins que dans les temps très anciens, on utilisait plutôt "Compact Pro" plutôt que StuffIt qui est arrivé plus tard.
J'utilise Stuffit Expander 4 sur System 6, et en effet l'auteur de mini vMac me dit qu'il faut général la version 5.5 pour décompresser les .sit de vieux softs qu'on trouve couramment sur le web. Mais elle ne tourne pas sur un Mac Plus, il faut émuler un LC II. Une version "early" de Compact Pro risque d'avoir le même problème. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Le 27/01/2019 à 20:19, Julien Salort a écrit :
pehache <pehache.7@gmail.com> wrote:
macOS ne gérant plus les volumes HFS en écriture depuis un bail, je
passe sous Linux pour monter l'image et copier le fichier dessus
Je ne suis pas sûr du tout que le Linux sache copier la section de
ressources du fichier, qui est indispensable sous les systèmes
classiques. Je ne suis pas sûr que le système de fichiers sous Linux
(ext4 ou autre) soit même capable de représenter la section de ressource
du fichier.
Je n'ai jamais compris comment c'était géré, cette histoire de
ressources... En pratique il me semblait que c'était un fichier caché
associé au fichier principal, non ?
À l'époque, on utilisait surtout le Binhex (extension hqx)
lorsque le fichier devait aller sur un Unix. Donc souvent, les fichiers
sont .sit.hqx lorsqu'ils transitent sur Internet. Le Binhex permet de
mettre la section de données et la section de ressources dans un fichier
lisible par un Unix.
Je pense que le mieux serait de récupérer une version de Stuffit
Expander compatible avec le System 6 et de dé-binhexer et décompresser
sur le vieux système directement.
Il me semble néanmoins que dans les temps très anciens, on utilisait
plutôt "Compact Pro" plutôt que StuffIt qui est arrivé plus tard.
J'utilise Stuffit Expander 4 sur System 6, et en effet l'auteur de mini
vMac me dit qu'il faut général la version 5.5 pour décompresser les .sit
de vieux softs qu'on trouve couramment sur le web. Mais elle ne tourne
pas sur un Mac Plus, il faut émuler un LC II. Une version "early" de
Compact Pro risque d'avoir le même problème.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
macOS ne gérant plus les volumes HFS en écriture depuis un bail, je passe sous Linux pour monter l'image et copier le fichier dessus sudo mkdir floppy sudo mount -t hfs -o loop 800K.dsk floppy sudo cp "Graphing Calculator 1.2" floppy sudo umount floppy
Je ne suis pas sûr du tout que le Linux sache copier la section de ressources du fichier, qui est indispensable sous les systèmes classiques. Je ne suis pas sûr que le système de fichiers sous Linux (ext4 ou autre) soit même capable de représenter la section de ressource du fichier.
Je n'ai jamais compris comment c'était géré, cette histoire de ressources... En pratique il me semblait que c'était un fichier caché associé au fichier principal, non ?
À l'époque, on utilisait surtout le Binhex (extension hqx) lorsque le fichier devait aller sur un Unix. Donc souvent, les fichiers sont .sit.hqx lorsqu'ils transitent sur Internet. Le Binhex permet de mettre la section de données et la section de ressources dans un fichier lisible par un Unix. Je pense que le mieux serait de récupérer une version de Stuffit Expander compatible avec le System 6 et de dé-binhexer et décompresser sur le vieux système directement. Il me semble néanmoins que dans les temps très anciens, on utilisait plutôt "Compact Pro" plutôt que StuffIt qui est arrivé plus tard.
J'utilise Stuffit Expander 4 sur System 6, et en effet l'auteur de mini vMac me dit qu'il faut général la version 5.5 pour décompresser les .sit de vieux softs qu'on trouve couramment sur le web. Mais elle ne tourne pas sur un Mac Plus, il faut émuler un LC II. Une version "early" de Compact Pro risque d'avoir le même problème. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Pascal J. Bourguignon
pehache writes:
Le 27/01/2019 à 20:19, Julien Salort a écrit :
pehache wrote:
macOS ne gérant plus les volumes HFS en écriture depuis un bail, je passe sous Linux pour monter l'image et copier le fichier dessus sudo mkdir floppy sudo mount -t hfs -o loop 800K.dsk floppy sudo cp "Graphing Calculator 1.2" floppy sudo umount floppy
Je ne suis pas sûr du tout que le Linux sache copier la section de ressources du fichier, qui est indispensable sous les systèmes classiques. Je ne suis pas sûr que le système de fichiers sous Linux (ext4 ou autre) soit même capable de représenter la section de ressource du fichier.
Je n'ai jamais compris comment c'était géré, cette histoire de ressources... En pratique il me semblait que c'était un fichier caché associé au fichier principal, non ?
Non. Au niveau du système de fichier, un fichier est composé de deux fourches (fork): une fourche donnée, et une fourche ressource. Chacune des fourches est une séquence d'octet. Mais toutes les meta informations (nom du fichier, date de création, etc) concernent les deux fourches: c'est un seul objet, manipulable comme un tout. Ensuite, on ajoute une couche "Resource Manager" pour gérer les ressources, des blocs de donnée identifiés par un type et un ID (tout deux de 32 bits). Le "Resource Manager" gère tout les fourches ressources ouverte dans le processus, les ressources des fichiers ouvert en dernier pouvant masquer les ressources des fichiers ouverts en premier. Notament, le code exécutable d'une application est enregistré dans des ressources de type 'CODE' = 434F4445(hex) = 1129268293(dec). CODE#0 contenant une table de sauts, et CODE#1 normalement le premier segment de code (main). Les autres segments de code sont chargés à la demande, via la table de sauts. Cette notion de fourche existe dans d'autres systèmes de fichiers, où elle n'est pas limitée à deux fourches. Mais en effet, pas sur les systèmes de fichier natif Linux comme ext2-ext4. Cependant Apple a spécifié trois façons d'enregistrer les informations d'un fichier Apple sur un système de fichier plat: - AppleSingle : tout est enregistré dans un seul fichier. - AppleDouble : la fourche donnée est enregistrée telle-quelle dans un fichier plat, les meta-informations ("informations Finder") et la fourche ressource est enregistrée dans un second fichier plat. - AppleTriple : les trois parties sont enregistrées dans trois fichiers plats séparés. https://en.wikipedia.org/wiki/AppleSingle_and_AppleDouble_formats Normalement, le montage d'un système de fichier HFS sur unix devrait montrer les fichiers au format AppleDouble, avec la fourche ressource + informations Finder d'un fichier "Nom" dans le fichier plat nommé "._Nom". Il peut aussi y avoir des options de montage pour utiliser AppleSingle ou AppleTripple. -- __Pascal J. Bourguignon__ http://www.informatimago.com
pehache <pehache.7@gmail.com> writes:
Le 27/01/2019 à 20:19, Julien Salort a écrit :
pehache <pehache.7@gmail.com> wrote:
macOS ne gérant plus les volumes HFS en écriture depuis un bail, je
passe sous Linux pour monter l'image et copier le fichier dessus
Je ne suis pas sûr du tout que le Linux sache copier la section de
ressources du fichier, qui est indispensable sous les systèmes
classiques. Je ne suis pas sûr que le système de fichiers sous Linux
(ext4 ou autre) soit même capable de représenter la section de ressource
du fichier.
Je n'ai jamais compris comment c'était géré, cette histoire de
ressources... En pratique il me semblait que c'était un fichier caché
associé au fichier principal, non ?
Non.
Au niveau du système de fichier, un fichier est composé de deux fourches
(fork): une fourche donnée, et une fourche ressource. Chacune des
fourches est une séquence d'octet. Mais toutes les meta informations
(nom du fichier, date de création, etc) concernent les deux fourches:
c'est un seul objet, manipulable comme un tout.
Ensuite, on ajoute une couche "Resource Manager" pour gérer les
ressources, des blocs de donnée identifiés par un type et un ID (tout
deux de 32 bits). Le "Resource Manager" gère tout les fourches
ressources ouverte dans le processus, les ressources des fichiers ouvert
en dernier pouvant masquer les ressources des fichiers ouverts en
premier.
Notament, le code exécutable d'une application est enregistré dans des
ressources de type 'CODE' = 434F4445(hex) = 1129268293(dec). CODE#0
contenant une table de sauts, et CODE#1 normalement le premier segment
de code (main). Les autres segments de code sont chargés à la demande,
via la table de sauts.
Cette notion de fourche existe dans d'autres systèmes de fichiers, où
elle n'est pas limitée à deux fourches. Mais en effet, pas sur les
systèmes de fichier natif Linux comme ext2-ext4.
Cependant Apple a spécifié trois façons d'enregistrer les informations
d'un fichier Apple sur un système de fichier plat:
- AppleSingle : tout est enregistré dans un seul fichier.
- AppleDouble : la fourche donnée est enregistrée telle-quelle dans un
fichier plat, les meta-informations ("informations
Finder") et la fourche ressource est enregistrée dans un
second fichier plat.
- AppleTriple : les trois parties sont enregistrées dans trois fichiers
plats séparés.
Normalement, le montage d'un système de fichier HFS sur unix devrait
montrer les fichiers au format AppleDouble, avec la fourche ressource
+ informations Finder d'un fichier "Nom" dans le fichier plat nommé
"._Nom". Il peut aussi y avoir des options de montage pour utiliser
AppleSingle ou AppleTripple.
--
__Pascal J. Bourguignon__
http://www.informatimago.com
macOS ne gérant plus les volumes HFS en écriture depuis un bail, je passe sous Linux pour monter l'image et copier le fichier dessus sudo mkdir floppy sudo mount -t hfs -o loop 800K.dsk floppy sudo cp "Graphing Calculator 1.2" floppy sudo umount floppy
Je ne suis pas sûr du tout que le Linux sache copier la section de ressources du fichier, qui est indispensable sous les systèmes classiques. Je ne suis pas sûr que le système de fichiers sous Linux (ext4 ou autre) soit même capable de représenter la section de ressource du fichier.
Je n'ai jamais compris comment c'était géré, cette histoire de ressources... En pratique il me semblait que c'était un fichier caché associé au fichier principal, non ?
Non. Au niveau du système de fichier, un fichier est composé de deux fourches (fork): une fourche donnée, et une fourche ressource. Chacune des fourches est une séquence d'octet. Mais toutes les meta informations (nom du fichier, date de création, etc) concernent les deux fourches: c'est un seul objet, manipulable comme un tout. Ensuite, on ajoute une couche "Resource Manager" pour gérer les ressources, des blocs de donnée identifiés par un type et un ID (tout deux de 32 bits). Le "Resource Manager" gère tout les fourches ressources ouverte dans le processus, les ressources des fichiers ouvert en dernier pouvant masquer les ressources des fichiers ouverts en premier. Notament, le code exécutable d'une application est enregistré dans des ressources de type 'CODE' = 434F4445(hex) = 1129268293(dec). CODE#0 contenant une table de sauts, et CODE#1 normalement le premier segment de code (main). Les autres segments de code sont chargés à la demande, via la table de sauts. Cette notion de fourche existe dans d'autres systèmes de fichiers, où elle n'est pas limitée à deux fourches. Mais en effet, pas sur les systèmes de fichier natif Linux comme ext2-ext4. Cependant Apple a spécifié trois façons d'enregistrer les informations d'un fichier Apple sur un système de fichier plat: - AppleSingle : tout est enregistré dans un seul fichier. - AppleDouble : la fourche donnée est enregistrée telle-quelle dans un fichier plat, les meta-informations ("informations Finder") et la fourche ressource est enregistrée dans un second fichier plat. - AppleTriple : les trois parties sont enregistrées dans trois fichiers plats séparés. https://en.wikipedia.org/wiki/AppleSingle_and_AppleDouble_formats Normalement, le montage d'un système de fichier HFS sur unix devrait montrer les fichiers au format AppleDouble, avec la fourche ressource + informations Finder d'un fichier "Nom" dans le fichier plat nommé "._Nom". Il peut aussi y avoir des options de montage pour utiliser AppleSingle ou AppleTripple. -- __Pascal J. Bourguignon__ http://www.informatimago.com
pehache
Le 03/02/2019 à 16:33, Pascal J. Bourguignon a écrit :
pehache writes:
Le 27/01/2019 à 20:19, Julien Salort a écrit :
pehache wrote:
macOS ne gérant plus les volumes HFS en écriture depuis un bail, je passe sous Linux pour monter l'image et copier le fichier dessus sudo mkdir floppy sudo mount -t hfs -o loop 800K.dsk floppy sudo cp "Graphing Calculator 1.2" floppy sudo umount floppy
Je ne suis pas sûr du tout que le Linux sache copier la section de ressources du fichier, qui est indispensable sous les systèmes classiques. Je ne suis pas sûr que le système de fichiers sous Linux (ext4 ou autre) soit même capable de représenter la section de ressource du fichier.
Je n'ai jamais compris comment c'était géré, cette histoire de ressources... En pratique il me semblait que c'était un fichier caché associé au fichier principal, non ?
Non. Au niveau du système de fichier, un fichier est composé de deux fourches (fork): une fourche donnée, et une fourche ressource. Chacune des fourches est une séquence d'octet. Mais toutes les meta informations (nom du fichier, date de création, etc) concernent les deux fourches: c'est un seul objet, manipulable comme un tout. Ensuite, on ajoute une couche "Resource Manager" pour gérer les ressources, des blocs de donnée identifiés par un type et un ID (tout deux de 32 bits). Le "Resource Manager" gère tout les fourches ressources ouverte dans le processus, les ressources des fichiers ouvert en dernier pouvant masquer les ressources des fichiers ouverts en premier. Notament, le code exécutable d'une application est enregistré dans des ressources de type 'CODE' = 434F4445(hex) = 1129268293(dec). CODE#0 contenant une table de sauts, et CODE#1 normalement le premier segment de code (main). Les autres segments de code sont chargés à la demande, via la table de sauts. Cette notion de fourche existe dans d'autres systèmes de fichiers, où elle n'est pas limitée à deux fourches. Mais en effet, pas sur les systèmes de fichier natif Linux comme ext2-ext4. Cependant Apple a spécifié trois façons d'enregistrer les informations d'un fichier Apple sur un système de fichier plat: - AppleSingle : tout est enregistré dans un seul fichier. - AppleDouble : la fourche donnée est enregistrée telle-quelle dans un fichier plat, les meta-informations ("informations Finder") et la fourche ressource est enregistrée dans un second fichier plat. - AppleTriple : les trois parties sont enregistrées dans trois fichiers plats séparés. https://en.wikipedia.org/wiki/AppleSingle_and_AppleDouble_formats Normalement, le montage d'un système de fichier HFS sur unix devrait montrer les fichiers au format AppleDouble, avec la fourche ressource + informations Finder d'un fichier "Nom" dans le fichier plat nommé "._Nom". Il peut aussi y avoir des options de montage pour utiliser AppleSingle ou AppleTripple.
Ah oui, je me souviens avoir eu affaire à l'AppleDouble en utilisant MAE il y a... bien longtemps ! Merci -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Le 03/02/2019 à 16:33, Pascal J. Bourguignon a écrit :
pehache <pehache.7@gmail.com> writes:
Le 27/01/2019 à 20:19, Julien Salort a écrit :
pehache <pehache.7@gmail.com> wrote:
macOS ne gérant plus les volumes HFS en écriture depuis un bail, je
passe sous Linux pour monter l'image et copier le fichier dessus
Je ne suis pas sûr du tout que le Linux sache copier la section de
ressources du fichier, qui est indispensable sous les systèmes
classiques. Je ne suis pas sûr que le système de fichiers sous Linux
(ext4 ou autre) soit même capable de représenter la section de ressource
du fichier.
Je n'ai jamais compris comment c'était géré, cette histoire de
ressources... En pratique il me semblait que c'était un fichier caché
associé au fichier principal, non ?
Non.
Au niveau du système de fichier, un fichier est composé de deux fourches
(fork): une fourche donnée, et une fourche ressource. Chacune des
fourches est une séquence d'octet. Mais toutes les meta informations
(nom du fichier, date de création, etc) concernent les deux fourches:
c'est un seul objet, manipulable comme un tout.
Ensuite, on ajoute une couche "Resource Manager" pour gérer les
ressources, des blocs de donnée identifiés par un type et un ID (tout
deux de 32 bits). Le "Resource Manager" gère tout les fourches
ressources ouverte dans le processus, les ressources des fichiers ouvert
en dernier pouvant masquer les ressources des fichiers ouverts en
premier.
Notament, le code exécutable d'une application est enregistré dans des
ressources de type 'CODE' = 434F4445(hex) = 1129268293(dec). CODE#0
contenant une table de sauts, et CODE#1 normalement le premier segment
de code (main). Les autres segments de code sont chargés à la demande,
via la table de sauts.
Cette notion de fourche existe dans d'autres systèmes de fichiers, où
elle n'est pas limitée à deux fourches. Mais en effet, pas sur les
systèmes de fichier natif Linux comme ext2-ext4.
Cependant Apple a spécifié trois façons d'enregistrer les informations
d'un fichier Apple sur un système de fichier plat:
- AppleSingle : tout est enregistré dans un seul fichier.
- AppleDouble : la fourche donnée est enregistrée telle-quelle dans un
fichier plat, les meta-informations ("informations
Finder") et la fourche ressource est enregistrée dans un
second fichier plat.
- AppleTriple : les trois parties sont enregistrées dans trois fichiers
plats séparés.
Normalement, le montage d'un système de fichier HFS sur unix devrait
montrer les fichiers au format AppleDouble, avec la fourche ressource
+ informations Finder d'un fichier "Nom" dans le fichier plat nommé
"._Nom". Il peut aussi y avoir des options de montage pour utiliser
AppleSingle ou AppleTripple.
Ah oui, je me souviens avoir eu affaire à l'AppleDouble en utilisant MAE
il y a... bien longtemps !
Merci
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Le 03/02/2019 à 16:33, Pascal J. Bourguignon a écrit :
pehache writes:
Le 27/01/2019 à 20:19, Julien Salort a écrit :
pehache wrote:
macOS ne gérant plus les volumes HFS en écriture depuis un bail, je passe sous Linux pour monter l'image et copier le fichier dessus sudo mkdir floppy sudo mount -t hfs -o loop 800K.dsk floppy sudo cp "Graphing Calculator 1.2" floppy sudo umount floppy
Je ne suis pas sûr du tout que le Linux sache copier la section de ressources du fichier, qui est indispensable sous les systèmes classiques. Je ne suis pas sûr que le système de fichiers sous Linux (ext4 ou autre) soit même capable de représenter la section de ressource du fichier.
Je n'ai jamais compris comment c'était géré, cette histoire de ressources... En pratique il me semblait que c'était un fichier caché associé au fichier principal, non ?
Non. Au niveau du système de fichier, un fichier est composé de deux fourches (fork): une fourche donnée, et une fourche ressource. Chacune des fourches est une séquence d'octet. Mais toutes les meta informations (nom du fichier, date de création, etc) concernent les deux fourches: c'est un seul objet, manipulable comme un tout. Ensuite, on ajoute une couche "Resource Manager" pour gérer les ressources, des blocs de donnée identifiés par un type et un ID (tout deux de 32 bits). Le "Resource Manager" gère tout les fourches ressources ouverte dans le processus, les ressources des fichiers ouvert en dernier pouvant masquer les ressources des fichiers ouverts en premier. Notament, le code exécutable d'une application est enregistré dans des ressources de type 'CODE' = 434F4445(hex) = 1129268293(dec). CODE#0 contenant une table de sauts, et CODE#1 normalement le premier segment de code (main). Les autres segments de code sont chargés à la demande, via la table de sauts. Cette notion de fourche existe dans d'autres systèmes de fichiers, où elle n'est pas limitée à deux fourches. Mais en effet, pas sur les systèmes de fichier natif Linux comme ext2-ext4. Cependant Apple a spécifié trois façons d'enregistrer les informations d'un fichier Apple sur un système de fichier plat: - AppleSingle : tout est enregistré dans un seul fichier. - AppleDouble : la fourche donnée est enregistrée telle-quelle dans un fichier plat, les meta-informations ("informations Finder") et la fourche ressource est enregistrée dans un second fichier plat. - AppleTriple : les trois parties sont enregistrées dans trois fichiers plats séparés. https://en.wikipedia.org/wiki/AppleSingle_and_AppleDouble_formats Normalement, le montage d'un système de fichier HFS sur unix devrait montrer les fichiers au format AppleDouble, avec la fourche ressource + informations Finder d'un fichier "Nom" dans le fichier plat nommé "._Nom". Il peut aussi y avoir des options de montage pour utiliser AppleSingle ou AppleTripple.
Ah oui, je me souviens avoir eu affaire à l'AppleDouble en utilisant MAE il y a... bien longtemps ! Merci -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
