je fais des logiciels avec interface graphique sommaire, qui deviennent
quand ils sont compilés des "fichiers exécutables unix" qui marchent
très bien si on les ouvre avec x11
avant la dernière fois où j'ai réinstallé mon système, quand je
compilais un logiciel, le logiciel avec lequel le finder voulait ouvrir
ce fichier était x11, et c'était très bien :-)
maintenant, plus moyen :-(
dans les infos c'est "aucun", et quand je clique dessus c'est le
terminal (qui ne veut pas ouvrir x11 dans la foulée)
est ce que qqn a une idée de ce qui peut influer là dessus ?
Ta phrase est ambigüe : sous MacOSX, la comande file reconnaît bel et bien les types de fichiers spécifiques à MacOS(X).
Ma phrase n'est pas ambigüe. J'ai parlé de Mac OS, pas de Mac OS X. Mac OS (càd Classic) n'étant pas Unix n'a pas le Magic Number. -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Xavier <xavier@groumpf.org> wrote:
Ta phrase est ambigüe : sous MacOSX, la comande file reconnaît bel et
bien les types de fichiers spécifiques à MacOS(X).
Ma phrase n'est pas ambigüe. J'ai parlé de Mac OS, pas de Mac OS X.
Mac OS (càd Classic) n'étant pas Unix n'a pas le Magic Number.
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Ta phrase est ambigüe : sous MacOSX, la comande file reconnaît bel et bien les types de fichiers spécifiques à MacOS(X).
Ma phrase n'est pas ambigüe. J'ai parlé de Mac OS, pas de Mac OS X. Mac OS (càd Classic) n'étant pas Unix n'a pas le Magic Number. -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
xavier
JiPaul wrote:
Ma phrase n'est pas ambigüe. J'ai parlé de Mac OS, pas de Mac OS X.
My mistake :-)
-- XAv - recasé
JiPaul <blanc@empty.org> wrote:
Ma phrase n'est pas ambigüe. J'ai parlé de Mac OS, pas de Mac OS X.
Ma phrase n'est pas ambigüe. J'ai parlé de Mac OS, pas de Mac OS X.
My mistake :-)
-- XAv - recasé
Patrick Stadelmann
In article <1jjm96o.18rhedpb7rlfkN%, (JiPaul) wrote:
Patrick Stadelmann wrote:
> Je ne crois pas. Si en 10.5.8 tu fais par exemple "cp -X test.jpg test", > "test" sera un fichier "plain text" pour le Finder. Si tu "chmod +x" ca > devient un exécutable Unix.
Non. Là tu confonds mode d'accès (ou autorisations) et types de fichier.
Pas du tout, en tout cas en 10.5.8 ça se passe comme expliqué.
Patrick -- Patrick Stadelmann
In article <1jjm96o.18rhedpb7rlfkN%blanc@empty.org>,
blanc@empty.org (JiPaul) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> Je ne crois pas. Si en 10.5.8 tu fais par exemple "cp -X test.jpg test",
> "test" sera un fichier "plain text" pour le Finder. Si tu "chmod +x" ca
> devient un exécutable Unix.
Non. Là tu confonds mode d'accès (ou autorisations) et types de fichier.
Pas du tout, en tout cas en 10.5.8 ça se passe comme expliqué.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1jjm96o.18rhedpb7rlfkN%, (JiPaul) wrote:
Patrick Stadelmann wrote:
> Je ne crois pas. Si en 10.5.8 tu fais par exemple "cp -X test.jpg test", > "test" sera un fichier "plain text" pour le Finder. Si tu "chmod +x" ca > devient un exécutable Unix.
Non. Là tu confonds mode d'accès (ou autorisations) et types de fichier.
Pas du tout, en tout cas en 10.5.8 ça se passe comme expliqué.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article <1jjm8lr.1499o9p1jg1uheN%, (JiPaul) wrote:
Nicolas Michel wrote:
> Que faisait mac os x quand il n'y avait ni extension ni type/creator ?
??? Type et creator existent depuis Mac OS (Classic). Ça remonte au moins à System 5. Quant aux extensions, héritées d'Unix, elles ont été interprétées dès le début de Mac OS X.
"quand il n'y avait" est à comprendre comme "quand un fichier n'avait" !
Patrick -- Patrick Stadelmann
In article <1jjm8lr.1499o9p1jg1uheN%blanc@empty.org>,
blanc@empty.org (JiPaul) wrote:
Nicolas Michel <NicolasAlex.Michel.remove@epfl.ch> wrote:
> Que faisait mac os x quand il n'y avait ni extension ni type/creator ?
???
Type et creator existent depuis Mac OS (Classic). Ça remonte au moins à
System 5. Quant aux extensions, héritées d'Unix, elles ont été
interprétées dès le début de Mac OS X.
"quand il n'y avait" est à comprendre comme "quand un fichier n'avait" !
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1jjm8lr.1499o9p1jg1uheN%, (JiPaul) wrote:
Nicolas Michel wrote:
> Que faisait mac os x quand il n'y avait ni extension ni type/creator ?
??? Type et creator existent depuis Mac OS (Classic). Ça remonte au moins à System 5. Quant aux extensions, héritées d'Unix, elles ont été interprétées dès le début de Mac OS X.
"quand il n'y avait" est à comprendre comme "quand un fichier n'avait" !
Patrick -- Patrick Stadelmann
blanc
Patrick Stadelmann wrote:
> > Je ne crois pas. Si en 10.5.8 tu fais par exemple "cp -X test.jpg test", > > "test" sera un fichier "plain text" pour le Finder. Si tu "chmod +x" ca > > devient un exécutable Unix. > > Non. Là tu confonds mode d'accès (ou autorisations) et types de fichier.
Pas du tout, en tout cas en 10.5.8 ça se passe comme expliqué.
Je ne conteste pas : ton cp -X copie en supprimant extension et attribus étendus (ainsi que ressource fork). Donc tu fais croire à Mac OS X que le fichier est ordinaire. Il reste malgré tout le Magic Number dont je parle par ailleurs. Si ton fichier était bien une image au départ et si tu fais la commande :
file test*
tu t'apercevras que ton fichier test (sans extension) est toujours reconnu comme une image de type jpeg :
test.jpg: JPEG image data, JFIF standard 1.01, comment: "AppleMark" test: JPEG image data, JFIF standard 1.01, comment: "AppleMark"
Et tu peux d'ailleurs l'ouvrir sans problème avec un logiciel photo tel que GC.
Mais ma remarque concernait en fait ta deuxième phrase. Si tu fais la commande :
chmod u+x test
tu ne transformes pas le fichier en exécutable Unix, tu lui donnes juste le droit d'exécution.
D'ailleurs, si tu essayes de l'exécuter tu auras une erreur :
zsh: exec format error: ./test
qu montre que Unix essaye d'exécuter ton fichier comme si c'était un script du shell courant.
La seule manière d'obtenir un "exécutable Unix", c'est de faire une compilation avec édition de liens de fichiers sources de langage correspondant à ton compilateur.
Tu peux aussi donner le droit d'exécution à un script, ce qui permet de l'exécuter en appelant juste son nom, plutôt que d'avoir à appeler le shell correspondant. Mais ce n'est pas non plus ce qu'on appelle un exécutable Unix.
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> > Je ne crois pas. Si en 10.5.8 tu fais par exemple "cp -X test.jpg test",
> > "test" sera un fichier "plain text" pour le Finder. Si tu "chmod +x" ca
> > devient un exécutable Unix.
>
> Non. Là tu confonds mode d'accès (ou autorisations) et types de fichier.
Pas du tout, en tout cas en 10.5.8 ça se passe comme expliqué.
Je ne conteste pas : ton cp -X copie en supprimant extension et attribus
étendus (ainsi que ressource fork). Donc tu fais croire à Mac OS X que
le fichier est ordinaire. Il reste malgré tout le Magic Number dont je
parle par ailleurs. Si ton fichier était bien une image au départ et si
tu fais la commande :
file test*
tu t'apercevras que ton fichier test (sans extension) est toujours
reconnu comme une image de type jpeg :
test.jpg: JPEG image data, JFIF standard 1.01, comment: "AppleMark"
test: JPEG image data, JFIF standard 1.01, comment: "AppleMark"
Et tu peux d'ailleurs l'ouvrir sans problème avec un logiciel photo tel
que GC.
Mais ma remarque concernait en fait ta deuxième phrase. Si tu fais la
commande :
chmod u+x test
tu ne transformes pas le fichier en exécutable Unix, tu lui donnes juste
le droit d'exécution.
D'ailleurs, si tu essayes de l'exécuter tu auras une erreur :
zsh: exec format error: ./test
qu montre que Unix essaye d'exécuter ton fichier comme si c'était un
script du shell courant.
La seule manière d'obtenir un "exécutable Unix", c'est de faire une
compilation avec édition de liens de fichiers sources de langage
correspondant à ton compilateur.
Tu peux aussi donner le droit d'exécution à un script, ce qui permet de
l'exécuter en appelant juste son nom, plutôt que d'avoir à appeler le
shell correspondant. Mais ce n'est pas non plus ce qu'on appelle un
exécutable Unix.
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
> > Je ne crois pas. Si en 10.5.8 tu fais par exemple "cp -X test.jpg test", > > "test" sera un fichier "plain text" pour le Finder. Si tu "chmod +x" ca > > devient un exécutable Unix. > > Non. Là tu confonds mode d'accès (ou autorisations) et types de fichier.
Pas du tout, en tout cas en 10.5.8 ça se passe comme expliqué.
Je ne conteste pas : ton cp -X copie en supprimant extension et attribus étendus (ainsi que ressource fork). Donc tu fais croire à Mac OS X que le fichier est ordinaire. Il reste malgré tout le Magic Number dont je parle par ailleurs. Si ton fichier était bien une image au départ et si tu fais la commande :
file test*
tu t'apercevras que ton fichier test (sans extension) est toujours reconnu comme une image de type jpeg :
test.jpg: JPEG image data, JFIF standard 1.01, comment: "AppleMark" test: JPEG image data, JFIF standard 1.01, comment: "AppleMark"
Et tu peux d'ailleurs l'ouvrir sans problème avec un logiciel photo tel que GC.
Mais ma remarque concernait en fait ta deuxième phrase. Si tu fais la commande :
chmod u+x test
tu ne transformes pas le fichier en exécutable Unix, tu lui donnes juste le droit d'exécution.
D'ailleurs, si tu essayes de l'exécuter tu auras une erreur :
zsh: exec format error: ./test
qu montre que Unix essaye d'exécuter ton fichier comme si c'était un script du shell courant.
La seule manière d'obtenir un "exécutable Unix", c'est de faire une compilation avec édition de liens de fichiers sources de langage correspondant à ton compilateur.
Tu peux aussi donner le droit d'exécution à un script, ce qui permet de l'exécuter en appelant juste son nom, plutôt que d'avoir à appeler le shell correspondant. Mais ce n'est pas non plus ce qu'on appelle un exécutable Unix.
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
blanc
Patrick Stadelmann wrote:
"quand il n'y avait" est à comprendre comme "quand un fichier n'avait" !
Ah ! D'accord :-) -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
"quand il n'y avait" est à comprendre comme "quand un fichier n'avait" !
Ah ! D'accord :-)
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
"quand il n'y avait" est à comprendre comme "quand un fichier n'avait" !
Ah ! D'accord :-) -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Patrick Stadelmann
In article <1jjnmm5.1dy59t01gsey2oN%, (JiPaul) wrote:
Je ne conteste pas : ton cp -X copie en supprimant extension et attribus étendus (ainsi que ressource fork). Donc tu fais croire à Mac OS X que le fichier est ordinaire.
C'était bien ça le but, montrer que Mac OS X n'utilise pas le contenu du fichier pour déterminer son type. C'est d'ailleurs toujours le cas avec Snow Leopard.
Patrick -- Patrick Stadelmann
In article <1jjnmm5.1dy59t01gsey2oN%blanc@empty.org>,
blanc@empty.org (JiPaul) wrote:
Je ne conteste pas : ton cp -X copie en supprimant extension et attribus
étendus (ainsi que ressource fork). Donc tu fais croire à Mac OS X que
le fichier est ordinaire.
C'était bien ça le but, montrer que Mac OS X n'utilise pas le contenu du
fichier pour déterminer son type. C'est d'ailleurs toujours le cas avec
Snow Leopard.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1jjnmm5.1dy59t01gsey2oN%, (JiPaul) wrote:
Je ne conteste pas : ton cp -X copie en supprimant extension et attribus étendus (ainsi que ressource fork). Donc tu fais croire à Mac OS X que le fichier est ordinaire.
C'était bien ça le but, montrer que Mac OS X n'utilise pas le contenu du fichier pour déterminer son type. C'est d'ailleurs toujours le cas avec Snow Leopard.
Patrick -- Patrick Stadelmann
Éric Lévénez
Le 06/06/10 11:07, Patrick Stadelmann a écrit :
C'était bien ça le but, montrer que Mac OS X n'utilise pas le contenu du fichier pour déterminer son type. C'est d'ailleurs toujours le cas avec Snow Leopard.
C'est vrai pour l'interface graphique, et encore beaucoup de programmes testent le contenu des fichiers pour voir le type. Par exemple un fichier "toto.gif" de type GIF, renommé en "toto.jpeg", s'ouvrira par double-clic dans Aperçu sans problème, car ce programme palpe le contenu du fichier pour trouver son type, et dans cet exemple il trouve un type GIF malgré le nom en jpeg.
Pour la partie unix, le type que trouve "file" est juste une estimation, il ne sert pas vraiment.
Le noyau connaît quelques types d'exécutables binaires par un magic number dans l'exécutable. Ce nombre indique par exemple si c'est un exécutable x86 ou ppc, si c'est du 32 bits ou du 64 bits... Si le magic number est inconnu, alors le noyau lance le shell "sh" (type Bourne Shell) pour exécuter le shell sensé se contenir dans le fichier. Si les 2 premiers octets du fichier sont "#!" le noyau suppose que c'est un script dont le nom de l'exécutable (et des options de lancement) se trouve après ce 2 octets. Sous NeXTSTEP, Mac OS X et iPhone OS, il y a aussi la notion de Fat Binary ou Universal Binary de Mach-O qui permet de stocker dans le fichier plusieurs types d'exécutables, et c'est là aussi le noyau qui utilisera celui le mieux adapté au système et au CPU.
C'est donc bien le contenu de l'exécutable unix qui sert à lancer tel ou tel programme, mais cela par l'interface posix. L'interface graphique ayant sa propre logique.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 06/06/10 11:07, Patrick Stadelmann a écrit :
C'était bien ça le but, montrer que Mac OS X n'utilise pas le contenu du
fichier pour déterminer son type. C'est d'ailleurs toujours le cas avec
Snow Leopard.
C'est vrai pour l'interface graphique, et encore beaucoup de programmes
testent le contenu des fichiers pour voir le type. Par exemple un
fichier "toto.gif" de type GIF, renommé en "toto.jpeg", s'ouvrira par
double-clic dans Aperçu sans problème, car ce programme palpe le contenu
du fichier pour trouver son type, et dans cet exemple il trouve un type
GIF malgré le nom en jpeg.
Pour la partie unix, le type que trouve "file" est juste une estimation,
il ne sert pas vraiment.
Le noyau connaît quelques types d'exécutables binaires par un magic
number dans l'exécutable. Ce nombre indique par exemple si c'est un
exécutable x86 ou ppc, si c'est du 32 bits ou du 64 bits... Si le magic
number est inconnu, alors le noyau lance le shell "sh" (type Bourne
Shell) pour exécuter le shell sensé se contenir dans le fichier. Si les
2 premiers octets du fichier sont "#!" le noyau suppose que c'est un
script dont le nom de l'exécutable (et des options de lancement) se
trouve après ce 2 octets. Sous NeXTSTEP, Mac OS X et iPhone OS, il y a
aussi la notion de Fat Binary ou Universal Binary de Mach-O qui permet
de stocker dans le fichier plusieurs types d'exécutables, et c'est là
aussi le noyau qui utilisera celui le mieux adapté au système et au CPU.
C'est donc bien le contenu de l'exécutable unix qui sert à lancer tel ou
tel programme, mais cela par l'interface posix. L'interface graphique
ayant sa propre logique.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
C'était bien ça le but, montrer que Mac OS X n'utilise pas le contenu du fichier pour déterminer son type. C'est d'ailleurs toujours le cas avec Snow Leopard.
C'est vrai pour l'interface graphique, et encore beaucoup de programmes testent le contenu des fichiers pour voir le type. Par exemple un fichier "toto.gif" de type GIF, renommé en "toto.jpeg", s'ouvrira par double-clic dans Aperçu sans problème, car ce programme palpe le contenu du fichier pour trouver son type, et dans cet exemple il trouve un type GIF malgré le nom en jpeg.
Pour la partie unix, le type que trouve "file" est juste une estimation, il ne sert pas vraiment.
Le noyau connaît quelques types d'exécutables binaires par un magic number dans l'exécutable. Ce nombre indique par exemple si c'est un exécutable x86 ou ppc, si c'est du 32 bits ou du 64 bits... Si le magic number est inconnu, alors le noyau lance le shell "sh" (type Bourne Shell) pour exécuter le shell sensé se contenir dans le fichier. Si les 2 premiers octets du fichier sont "#!" le noyau suppose que c'est un script dont le nom de l'exécutable (et des options de lancement) se trouve après ce 2 octets. Sous NeXTSTEP, Mac OS X et iPhone OS, il y a aussi la notion de Fat Binary ou Universal Binary de Mach-O qui permet de stocker dans le fichier plusieurs types d'exécutables, et c'est là aussi le noyau qui utilisera celui le mieux adapté au système et au CPU.
C'est donc bien le contenu de l'exécutable unix qui sert à lancer tel ou tel programme, mais cela par l'interface posix. L'interface graphique ayant sa propre logique.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Patrick Stadelmann
In article <4c0bb92c$0$22367$, Éric Lévénez wrote:
Le 06/06/10 11:07, Patrick Stadelmann a écrit :
> C'était bien ça le but, montrer que Mac OS X n'utilise pas le contenu du > fichier pour déterminer son type. C'est d'ailleurs toujours le cas avec > Snow Leopard.
C'est vrai pour l'interface graphique, et encore beaucoup de programmes testent le contenu des fichiers pour voir le type.
Oui, le test concernait spécifiquement le comportement du Finder (et les Launch Services qu'il interroge probablement pour cela) pour déterminer le type d'un document qui n'a ni extensions ni type HFS.
C'est donc bien le contenu de l'exécutable unix qui sert à lancer tel ou tel programme, mais cela par l'interface posix.
OK, c'est donc de cela que Nicolas se souvenait.
L'interface graphique ayant sa propre logique.
Elle doit surtout gérer l'ouverture de documents (et donc déterminer quelle application lancer), ce que la couche posix ne gère pas du tout.
Patrick -- Patrick Stadelmann
In article <4c0bb92c$0$22367$426a34cc@news.free.fr>,
Éric Lévénez <usenet@levenez.com> wrote:
Le 06/06/10 11:07, Patrick Stadelmann a écrit :
> C'était bien ça le but, montrer que Mac OS X n'utilise pas le contenu du
> fichier pour déterminer son type. C'est d'ailleurs toujours le cas avec
> Snow Leopard.
C'est vrai pour l'interface graphique, et encore beaucoup de programmes
testent le contenu des fichiers pour voir le type.
Oui, le test concernait spécifiquement le comportement du Finder (et les
Launch Services qu'il interroge probablement pour cela) pour déterminer
le type d'un document qui n'a ni extensions ni type HFS.
C'est donc bien le contenu de l'exécutable unix qui sert à lancer tel ou
tel programme, mais cela par l'interface posix.
OK, c'est donc de cela que Nicolas se souvenait.
L'interface graphique ayant sa propre logique.
Elle doit surtout gérer l'ouverture de documents (et donc déterminer
quelle application lancer), ce que la couche posix ne gère pas du tout.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <4c0bb92c$0$22367$, Éric Lévénez wrote:
Le 06/06/10 11:07, Patrick Stadelmann a écrit :
> C'était bien ça le but, montrer que Mac OS X n'utilise pas le contenu du > fichier pour déterminer son type. C'est d'ailleurs toujours le cas avec > Snow Leopard.
C'est vrai pour l'interface graphique, et encore beaucoup de programmes testent le contenu des fichiers pour voir le type.
Oui, le test concernait spécifiquement le comportement du Finder (et les Launch Services qu'il interroge probablement pour cela) pour déterminer le type d'un document qui n'a ni extensions ni type HFS.
C'est donc bien le contenu de l'exécutable unix qui sert à lancer tel ou tel programme, mais cela par l'interface posix.
OK, c'est donc de cela que Nicolas se souvenait.
L'interface graphique ayant sa propre logique.
Elle doit surtout gérer l'ouverture de documents (et donc déterminer quelle application lancer), ce que la couche posix ne gère pas du tout.
Patrick -- Patrick Stadelmann
NicolasAlex.Michel.remove
JiPaul wrote:
Nicolas Michel wrote:
> Que faisait mac os x quand il n'y avait ni extension ni type/creator ?
??? Type et creator existent depuis Mac OS (Classic). Ça remonte au moins à System 5. Quant aux extensions, héritées d'Unix, elles ont été interprétées dès le début de Mac OS X.
Comme le dit patrick, ma question était :
Sous Mac OS X 10.3, que se passe-t-il si on tente d'ouvrir un fichier qui n'a ni type/creator ni extention.
C'est assez courant quand on récupère des fichiers Classic via du FAT ou du CIFS.
Il me semble qu'il y avait une détection du type de ficher. Bon, c'est de l'histoire ancienne, donc c'est pas grave.
Merci à tous pour vos explications :) -- Nicolas Michel
JiPaul <blanc@empty.org> wrote:
Nicolas Michel <NicolasAlex.Michel.remove@epfl.ch> wrote:
> Que faisait mac os x quand il n'y avait ni extension ni type/creator ?
???
Type et creator existent depuis Mac OS (Classic). Ça remonte au moins à
System 5. Quant aux extensions, héritées d'Unix, elles ont été
interprétées dès le début de Mac OS X.
Comme le dit patrick, ma question était :
Sous Mac OS X 10.3, que se passe-t-il si on tente d'ouvrir un fichier
qui n'a ni type/creator ni extention.
C'est assez courant quand on récupère des fichiers Classic via du FAT ou
du CIFS.
Il me semble qu'il y avait une détection du type de ficher.
Bon, c'est de l'histoire ancienne, donc c'est pas grave.
Merci à tous pour vos explications :)
--
Nicolas Michel
> Que faisait mac os x quand il n'y avait ni extension ni type/creator ?
??? Type et creator existent depuis Mac OS (Classic). Ça remonte au moins à System 5. Quant aux extensions, héritées d'Unix, elles ont été interprétées dès le début de Mac OS X.
Comme le dit patrick, ma question était :
Sous Mac OS X 10.3, que se passe-t-il si on tente d'ouvrir un fichier qui n'a ni type/creator ni extention.
C'est assez courant quand on récupère des fichiers Classic via du FAT ou du CIFS.
Il me semble qu'il y avait une détection du type de ficher. Bon, c'est de l'histoire ancienne, donc c'est pas grave.
Merci à tous pour vos explications :) -- Nicolas Michel
