Créer un fichier avec une URL Internet dedans
Greensource
Membre
Je ne sais pas trop où poser cette question. C'est pas vraiment de la programmation mais ça me pose un souci quand même.
En gros je voudrais créer un fichier qui quand on clique dessus interprête l'URL qui y est contenu.
Par exemple un http://www.google.com lance Safari avec la page www.google.com
ou bien smb://a.b.c.d se connecte au serveur a.b.c.d
J'ai parfois vu des fichiers avec un icone de safari dedans c'est peu être ça? Mais pas moyen de remetre la main dessus.
Merci
En gros je voudrais créer un fichier qui quand on clique dessus interprête l'URL qui y est contenu.
Par exemple un http://www.google.com lance Safari avec la page www.google.com
ou bien smb://a.b.c.d se connecte au serveur a.b.c.d
J'ai parfois vu des fichiers avec un icone de safari dedans c'est peu être ça? Mais pas moyen de remetre la main dessus.
Merci
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Par contre, je ne sais pas trop comment ça fonctionne, le fichier est vide (ils utilisent le resource fork ou quoi ?)
[EDIT]
Exact, pour les favicons, l'URL est dans le resource fork !
Bon ça devrait disparaà®tre avec Snow Leopard j'imagine, le Finder étant entièrement Cocoatisé, et je suis pas sûr qu'on ait une API propre pour accéder aux rsrc forks sans passer par Carbon... donc ils ont dû en profiter pour changer ça je pense ?
Quoi ? du carbon pas propre dans léo tout blanc !!!
Sans rire, comment tu fais pour utiliser ton Mac sans le FileManager (100% genuine carbon inside)
Les resources forks disparaà®tront avec HFS, donc avec l'arrivée du zfs ?
Mais il paraà®t que zfs peut gérer les forks ...
Autant les metadatas d'un fichier, si c'est pas géré par le filesystem de destination, c'est simplement perdu/ignoré... mais c'est pas si grave, car c'est plutôt des infos comme "avec quoi je veux ouvrir ce fichier" ou "quelle couleur je donne à ce fichier dans le Finder" je crois, ou des infos spotlight, enfin il me semble que c'est à peu près ça que contiennent les métadatas, en tout cas rien de vital.
Autant les resourceforks contiennent des ressources, des données indispensables pour lire le fichier. Un TextClipping ou un favicon sans ses resourceforks ne sert plus à rien, on a perdu les données utiles...
Le pire c'est que ce genre de fichiers ne contient QUE des ressource forks, donc pourquoi ils ne les mettent pas dans la partie datafork (quitte à les formatter comme des fichiers de ressources, ce qui est fait pour certains autres fichiers d'ailleurs dans Léopard)... remarque je dis ça j'ai pas vérifié, si ça se trouve pour les clippings et les favicons c'est pas réellement dans les resourceforks, mais bien dans les dataforks, formatté comme des resourceforks.
Notez la présence des utilitaires en ligne de commande "Rez" et "DeRez" dans /Developer/Tools permettant de manipuler tout ça si besoin.
Par ce que tout ce que je trouve c'est une commande pour créer un nouveau processus ^^ Et je pense pas que vous parliez de ça?
Par exemple une application Carbon sous OS9 contenait souvent son code binaire (compilé) dans les data fork, et ses ressources (images, sons, design des boites de dialogue, ...) dans les resource fork.
On utilisait des logiciels comme ResEdit ou Resorcerer pour éditer la partie "resource fork" (alors que la partie "data fork" est celle à laquelle tu accèdes "normalement" en lisant le fichier, par exemple via un éditeur hexa ou un éditeur de texte).
Ce système pose le problème que les resource fork ne sont pas supportés par des filesystems comme ceux du monde Windows, donc transférer un fichier Mac sous Windows risquait de faire perdre des données (les resource forks justement, qui passaient du coup à la trappe) et menaçait donc l'intégrité du fichier. Maintenant les resource forks sont donc de moins en moins utilisées voire vouées à être abandonnées, et tout ce bazar est géré autrement.
Sauf pour des irréductibles comme les favicons ou les textclippings justement, qui résistent encore et toujours à l'uniformisation et gardent encore trace du passé apparemment...
http://en.wikipedia.org/wiki/Resource_fork
--
NB : Il me semble que quand tu crées une archive d'un dossier ou d'un fichier avec le Finder, si les fichiers à zipper contiennent des resourceForks, il les sépare du fichier et les mets dans un fichier à part (en recopiant ces resourceforks dans la partie datafork dudit nouveau fichier du coup) et met ce fichier dans un répertoire ".__MACOS_X" à la racine du zip. On appelle ça le "resource splitting", où l'on sépare les dataforks et resourceforks d'un fichier dans 2 fichiers séparés (chacun n'ayant alors plus qu'un datafork et pas de resourcefork).
C'est donc pour ça que tu peux voir ce genre de dossier ".__MACOS_X" dans les archives dézippées sous Windows si elles viennent du monde mac.
De plus, lors de la copie d'un fichier mac sur un volume Windows, si le fichier contient des resourceforks, elles sont aussi splittées dans un fichier séparé (et mises dans sa partie datafork), fichier qui a le même nom que le fichier d'origine... précédé de "._". C'est aussi donc de là que viennent tous ces fichiers "._machin" que tu peux parfois voir quand tu transfères des fichiers d'un Mac à un PC sous Windows...
Bref, vous aussi rejoignez moi dans le CPATRF (Comité Pour l'Abandon Total des Resource Forks) :P
Ca c'est cool de enfin savoir ça, je m'était toujours demandé ^^
Est-ce à dire qu'avec le Léopard des Neiges il ne sera plus là ?
Enfin disons qu'avec Snow Leopard, perso j'espère que tous les fichiers utilisés par le Finder abandonneront l'utilisation des resourceforks, donc en particulier que tous les fichiers gérés par OSX lui-même ne les utiliseront plus, textclippings, favicons et aliases compris.
Ce qui permettra si on utilise que des logiciels "standards" et "pas trop vieux" ou que des logiciels Apple, de ne plus manipuler de fichiers avec des data forks... et donc de ne plus jamais avoir de "._machin" (et de "__MACOS_X" dans les zip).
Maintenant je pense qu'Apple va garder la partie gestion de ces fichiers ayant des resource forks, par soucis de retrocompatibilité, c'est à dire que si malgré le fait que plus aucun service et plus aucune appli Mac de ton Snow Leopard (Finder compris) n'utilise plus de resourceforks, tu as quand même un fichier avec un resourcefork qui attérit sur ton mac (récupéré d'un vieux disque, d'une vieille appli, d'un pote qui a une version antérieure d'OSX, ...) il saura encore les gérer.
Mais j'espère juste qu'ils deviendront plus rares... quoique je suis médisant, c'est déjà progressivement le cas, avec OSX ils restent quand même relativement rares il me semble, à part ces quelques exceptions citées, c'est rien comparé à ce qu'on avait sous feu OS9 :P
Je programme depuis Mac OS 3 ou 4 ( :-\\ c'est vieux tout ça), à l'époque le ressource fork contenait tout le logiciel, même le code exécutable. Le code exécutable est, d'une certaine manière, une ressource du logiciel. Comme toutes les routines existaient pour manipuler le ressource fork, cela permettait de mettre à jour la partie buggué d'un logiciel en concervant le reste. Les fichiers de donnée avait normalement dans leur resourcefork les références de leur créateur et du type des données contenues. C'est de là que vient le "PkgInfo".
C'est avec MacOS 8 puis 9 et le PPC que l'on a vu le code exécutable passé dans le datafork. En fait le code 68xxx était logé dans le ressource fork et le code PPC dans le datafork (si je me souviens bien).
Avec les Bundles modernes les forks pourraient disparaitrent. Oui, mais Appel devrait changer un certain nombre d'automatismes comme les Alias qui gardent la trace du fichier d'origine, même s'il est déplacé!
Alors, je ne pense pas que les forks vont disparaitre rapidement et je ne suis pas sur que leur disparition soit souhaitable!
NB: quelqu'un peut-il me faire une émoticone avec une barbe blanche et une canne?
Je n'ai pas dit (et ne milite pas spécialement pour) que les ressources, et le format utilisé pour les ressources, allait disparaà®tre, mais juste les forks... et là c'est une grande nuance !
En effet pour reprendre ton exemple tu parles de fichier "Localized.rsrc". Ce genre de fichier n'a pas de fork. Il n'a pas un data fork et un resource fork. Il n'a qu'un data fork, dont les données sont formattées comme l'étaient les resource forks à l'époque de ResEdit & co.
C'est à dire que le fichier "Localized.rsrc" ne contient qu'une zone "data fork". Et dans cette zone, on trouve les octets arrangés exactement comme ils seraient arrangés dans la "resource fork" d'un fichier forké.
Mais si tu ouvres ce fichier avec un éditeur genre ResEdit, il ne trouvera pas de resources. Il faudrait passer le fichier Localized.rsrc à la moulinette d'outils comme Rez/DeRez/RezWack/UnRezWack pour copier les octets présents dans le data fork du fichier vers le resource fork de ce fichier (ou d'un nouveau), puis seulement ouvrir le fichier (celui dans lequel on a transféré les resources dans le resource fork) avec ResEdit.
Donc dans un fichier .r ou .rsrc le format des données, l'agencement des octets quoi, est le même que celui que l'on trouve dans un resource fork d'un fichier... sauf que ces données sont placées dans le "data fork" du fichier.
Tu peux faire le test, d'une part en copiant ce fichier "Localized.rsrc" par exemple sur un volume Windows, puis en le récupérant ensuite, tu verras qu'il est toujours intègre... ou sinon en faisant mumuse avec RezWack et UnRezWack pour passer les octets de ces ressources d'un fork à l'autre.
L'idée ce n'est donc pas de supprimer le format de données stockant des ressources (je crois que c'est un format un peu comme les formats RIFF, MOV et autres confrères, un code FOURCC, un ID, une longueur, et les données, les uns à la suite des autres), mais de transvaser ces octets binaires du resource fork au data fork pour ne plus avoir des fichiers n'ayant que des data forks (enfin n'ayant pas de forks, ayant tout dans leur partie données quoi).
Aller, je vais au pieu, c'est l'heure. A+
Car autant ResEdit je sais qu'il ne sait ouvrir que les resourceforks, autant je crois que Resourcerer est suffisamment "intelligent" pour ouvrir les resourceforks s'il y en a... mais si c'est un fichier ".rsrc" au format "resources dans le datafork, et pas de resourceforks", il sait automatiquement aller lire les resources dans le bon fork, justement parce qu'avec l'abandon progressif des resourceforks, ce format "on met les resources dans un fichier séparé non forké, plutôt que dans le fork "resources" d'un fichier forké est de plus en plus répandu sous OSX...
J'ai pas Toast pour tester, mais je suis prêt à parier que c'est le cas, c'est à dire que ton Localized.rsrc est comme celui que j'ai pris en exemple dans le bundle de iTunes, il n'est pas forké (il n'a que des data forks si tu veux) et c'est juste que Resorcerer est assez intelligent pour aller lire les resources dans le datafork quand le fichier n'est pas forké...
Désolé de gâcher ta joie, mais on peut y accéder directement avec les fonctions BSD elles-mêmes avec l'extension de path "/..namedfork/rsrc"
Par contre "en dur dans le kernel" ? Alors que ça dépend du filesystem ?! Etonnant...
Plusieurs choses fausses... Quand on copie sur un FS qui ne gère pas certaines données, tout est mis dans un fichier "._nom" (format AppleDouble) ; et dans le sens contraire, c'est également géré... Tout passe par "copyfile" (man copyfile)
Les infos Spotlight n'ont jamais été dans le rsrc... Dans 10.4, c'était dans les fichiers .DS_Store, dans 10.5, c'est un extended attribute.
Je ne crois pas à l'abandon des rsrc... Tout simplement pour la compatibilité ascendante
Au pire, ils peuvent ne plus l'utiliser pour les nouveaux (mais dans ce cas, les icônes des fichiers, tu les stockes où ??).
Dans la partie HSF du Kernel
Bossé sur un driver, il renvoyait ce genre de paths avec les "..namedford"
Il y a plusieurs choses bizarres codées en dur dans le Kernel... comme le uid / gid 99
Non, aucun problème avec AppleDouble qui gère tout ça pour la compatibilité entre FS
Tu as oublié le plus important... Les icônes des fichiers sont stockées dans les rsrc. Et AMHA c'est pas près de changer (toujours pour question de compatibilité ascendante !)
Pour tar, il utilise AppleDouble ; pour zip, je ne sait point ; peut-être un autre format.
Il n'y a pas que les ressources dans ces fichiers, tu y trouveras aussi les ACL, les extended attributes et tout un tas d'autres infos gérées par AppleDouble ; pareil, ils ne sont pas près de disparaà®tre !
Oui, ce ne sont pas des ressources... Mais ça n'empêche que c'est dans le format AppleDouble (les fichiers ._)
C'est pour ça qu'il faut bien différencier les deux... AppleDouble ≠Ressoures et même si les ressources disparaissent, les fichiers ._ sur les FS Windows resteront !