Rogntudjuuu!
Suite à un crash, le merveilleux CopyAgent 1.0.1 ne veut plus rien savoir.
Plus moyen de mettre la main dessus. Connectix, c'est fini.
Qui pourrait me le remplacer?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
syl_vain
Stephane Adam wrote:
Suite à un crash, le merveilleux CopyAgent 1.0.1 ne veut plus rien savoir. Plus moyen de mettre la main dessus. Connectix, c'est fini. Qui pourrait me le remplacer?
Regarde ici:
http://sbouju.mobile.free.fr/abandonware/
-- Sylvain Bouju --
Stephane Adam <fa218874@skynet.be> wrote:
Suite à un crash, le merveilleux CopyAgent 1.0.1 ne veut plus rien savoir.
Plus moyen de mettre la main dessus. Connectix, c'est fini.
Qui pourrait me le remplacer?
Suite à un crash, le merveilleux CopyAgent 1.0.1 ne veut plus rien savoir. Plus moyen de mettre la main dessus. Connectix, c'est fini. Qui pourrait me le remplacer?
Regarde ici:
http://sbouju.mobile.free.fr/abandonware/
-- Sylvain Bouju --
GetNextEvent
Dans l'article <1gxbesl.1qvxp4b15klcpyN%, (Sylvain Bouju) écrit:
Stephane Adam wrote:
> Suite à un crash, le merveilleux CopyAgent 1.0.1 ne veut plus rien savoir. > Plus moyen de mettre la main dessus. Connectix, c'est fini. > Qui pourrait me le remplacer?
Regarde ici:
http://sbouju.mobile.free.fr/abandonware/
Pour CopyAgent.smi, il a suffit de retyper le fichier en type: GImg créateur: ddsk et hop Disk Copy le monte sans problème.
Mais pour CopyAgent101Updater.smi, je sèche; c'est curieux ce format qui commence comme une image physique mais où à la fin il y a 33 octets de décallage.
Dans l'article <1gxbesl.1qvxp4b15klcpyN%syl_vain@bou_ju.net>,
syl_vain@bou_ju.net (Sylvain Bouju) écrit:
Stephane Adam <fa218874@skynet.be> wrote:
> Suite à un crash, le merveilleux CopyAgent 1.0.1 ne veut plus rien savoir.
> Plus moyen de mettre la main dessus. Connectix, c'est fini.
> Qui pourrait me le remplacer?
Regarde ici:
http://sbouju.mobile.free.fr/abandonware/
Pour CopyAgent.smi, il a suffit de retyper le fichier en
type: GImg créateur: ddsk
et hop Disk Copy le monte sans problème.
Mais pour CopyAgent101Updater.smi, je sèche; c'est curieux
ce format qui commence comme une image physique mais où
à la fin il y a 33 octets de décallage.
Dans l'article <1gxbesl.1qvxp4b15klcpyN%, (Sylvain Bouju) écrit:
Stephane Adam wrote:
> Suite à un crash, le merveilleux CopyAgent 1.0.1 ne veut plus rien savoir. > Plus moyen de mettre la main dessus. Connectix, c'est fini. > Qui pourrait me le remplacer?
Regarde ici:
http://sbouju.mobile.free.fr/abandonware/
Pour CopyAgent.smi, il a suffit de retyper le fichier en type: GImg créateur: ddsk et hop Disk Copy le monte sans problème.
Mais pour CopyAgent101Updater.smi, je sèche; c'est curieux ce format qui commence comme une image physique mais où à la fin il y a 33 octets de décallage.
syl_vain
GetNextEvent wrote:
Pour CopyAgent.smi, il a suffit de retyper le fichier en type: GImg créateur: ddsk et hop Disk Copy le monte sans problème.
Mais pour CopyAgent101Updater.smi, je sèche; c'est curieux ce format qui commence comme une image physique mais où à la fin il y a 33 octets de décallage.
Désolé, j'avais oublié de passer par la case zip. Cela devrait aller mieux maintenant...
-- Sylvain Bouju --
GetNextEvent <void@void.void> wrote:
Pour CopyAgent.smi, il a suffit de retyper le fichier en
type: GImg créateur: ddsk
et hop Disk Copy le monte sans problème.
Mais pour CopyAgent101Updater.smi, je sèche; c'est curieux
ce format qui commence comme une image physique mais où
à la fin il y a 33 octets de décallage.
Désolé, j'avais oublié de passer par la case zip.
Cela devrait aller mieux maintenant...
Pour CopyAgent.smi, il a suffit de retyper le fichier en type: GImg créateur: ddsk et hop Disk Copy le monte sans problème.
Mais pour CopyAgent101Updater.smi, je sèche; c'est curieux ce format qui commence comme une image physique mais où à la fin il y a 33 octets de décallage.
Désolé, j'avais oublié de passer par la case zip. Cela devrait aller mieux maintenant...
> Pour CopyAgent.smi, il a suffit de retyper le fichier en > type: GImg créateur: ddsk > et hop Disk Copy le monte sans problème. > > Mais pour CopyAgent101Updater.smi, je sèche; c'est curieux > ce format qui commence comme une image physique mais où > à la fin il y a 33 octets de décallage.
Désolé, j'avais oublié de passer par la case zip. Cela devrait aller mieux maintenant...
C'est différent.
CA.zip est une archive que Stuffit Expnader 7.0.3 ne sait pas étendre (archive was compressed with an unknown compression method); pas trop grave, j'ai gardé la précédente image.
CAup101.zip s'étend, mais Data Fork et Recource Fork sont dans des fihiers différents; toutefois je vois à peu près comment les rassembler.
> Pour CopyAgent.smi, il a suffit de retyper le fichier en
> type: GImg créateur: ddsk
> et hop Disk Copy le monte sans problème.
>
> Mais pour CopyAgent101Updater.smi, je sèche; c'est curieux
> ce format qui commence comme une image physique mais où
> à la fin il y a 33 octets de décallage.
Désolé, j'avais oublié de passer par la case zip.
Cela devrait aller mieux maintenant...
C'est différent.
CA.zip est une archive que Stuffit Expnader 7.0.3 ne sait pas
étendre (archive was compressed with an unknown compression
method); pas trop grave, j'ai gardé la précédente image.
CAup101.zip s'étend, mais Data Fork et Recource Fork sont
dans des fihiers différents; toutefois je vois à peu près comment
les rassembler.
> Pour CopyAgent.smi, il a suffit de retyper le fichier en > type: GImg créateur: ddsk > et hop Disk Copy le monte sans problème. > > Mais pour CopyAgent101Updater.smi, je sèche; c'est curieux > ce format qui commence comme une image physique mais où > à la fin il y a 33 octets de décallage.
Désolé, j'avais oublié de passer par la case zip. Cela devrait aller mieux maintenant...
C'est différent.
CA.zip est une archive que Stuffit Expnader 7.0.3 ne sait pas étendre (archive was compressed with an unknown compression method); pas trop grave, j'ai gardé la précédente image.
CAup101.zip s'étend, mais Data Fork et Recource Fork sont dans des fihiers différents; toutefois je vois à peu près comment les rassembler.
Dans l'article <1gxdbux.152he3ff4y5l2N%, (Sylvain Bouju) écrit:
GetNextEvent wrote:
> C'est différent.
Et là?
Pas mieux. OS X a encore frappé :-(
CA.zip est plus petit, mais tout aussi indécodable. CA101Upd.zip est sensiblement pareil, c'est à dire que Data Fork et Ressource Fork sont dissociées.
Deux conseils pour transférer par ftp vers MacOS 9 - utiliser DropStuff (dans un format compatible avec la version 7 de Stuffit Expander) ce qui évite la séparation des Forks. - plutôt transférer des images disques, que des fichiers copiés d'une image disque montée, si l'image de départ a été crée sous MacOS 9 ou antérieur.
Note: une image disque faite par Disk Copy de MacOS 9 a souvent des informations indispensables dans la Resource Fork, c'est je crois ce qui est arrivé à CopyAgent101Updater.smi. Ces images disques doivent être passées par DropStuff avant transfert par ftp.
Note: une fois une image disque montée, le DiskCopy de MacOS X sait très bien en faire une image ".dmg" NON COMPRIMEES qui est rétrocompatibles avec Disk Copy (6.5bxx) de MacOS 9.
Note: Il est quand même utile de passer par DropStuff une image disque crée par le DiskCopy de MacOS X, car cela la comprime.
En tout cas merci pour les efforts; et avec ce que j'ai, je vais arriver à tout reconstituer.
Dans l'article <1gxdbux.152he3ff4y5l2N%syl_vain@bou_ju.net>,
syl_vain@bou_ju.net (Sylvain Bouju) écrit:
GetNextEvent <void@void.void> wrote:
> C'est différent.
Et là?
Pas mieux. OS X a encore frappé :-(
CA.zip est plus petit, mais tout aussi indécodable.
CA101Upd.zip est sensiblement pareil, c'est à dire que
Data Fork et Ressource Fork sont dissociées.
Deux conseils pour transférer par ftp vers MacOS 9
- utiliser DropStuff (dans un format compatible avec la version
7 de Stuffit Expander) ce qui évite la séparation des Forks.
- plutôt transférer des images disques, que des fichiers copiés
d'une image disque montée, si l'image de départ a été crée sous
MacOS 9 ou antérieur.
Note: une image disque faite par Disk Copy de MacOS 9 a souvent
des informations indispensables dans la Resource Fork, c'est je
crois ce qui est arrivé à CopyAgent101Updater.smi.
Ces images disques doivent être passées par DropStuff avant
transfert par ftp.
Note: une fois une image disque montée, le DiskCopy de MacOS X
sait très bien en faire une image ".dmg" NON COMPRIMEES qui
est rétrocompatibles avec Disk Copy (6.5bxx) de MacOS 9.
Note: Il est quand même utile de passer par DropStuff une image
disque crée par le DiskCopy de MacOS X, car cela la comprime.
En tout cas merci pour les efforts; et avec ce que j'ai, je vais
arriver à tout reconstituer.
Dans l'article <1gxdbux.152he3ff4y5l2N%, (Sylvain Bouju) écrit:
GetNextEvent wrote:
> C'est différent.
Et là?
Pas mieux. OS X a encore frappé :-(
CA.zip est plus petit, mais tout aussi indécodable. CA101Upd.zip est sensiblement pareil, c'est à dire que Data Fork et Ressource Fork sont dissociées.
Deux conseils pour transférer par ftp vers MacOS 9 - utiliser DropStuff (dans un format compatible avec la version 7 de Stuffit Expander) ce qui évite la séparation des Forks. - plutôt transférer des images disques, que des fichiers copiés d'une image disque montée, si l'image de départ a été crée sous MacOS 9 ou antérieur.
Note: une image disque faite par Disk Copy de MacOS 9 a souvent des informations indispensables dans la Resource Fork, c'est je crois ce qui est arrivé à CopyAgent101Updater.smi. Ces images disques doivent être passées par DropStuff avant transfert par ftp.
Note: une fois une image disque montée, le DiskCopy de MacOS X sait très bien en faire une image ".dmg" NON COMPRIMEES qui est rétrocompatibles avec Disk Copy (6.5bxx) de MacOS 9.
Note: Il est quand même utile de passer par DropStuff une image disque crée par le DiskCopy de MacOS X, car cela la comprime.
En tout cas merci pour les efforts; et avec ce que j'ai, je vais arriver à tout reconstituer.
syl_vain
GetNextEvent wrote:
Pas mieux. OS X a encore frappé :-(
Ouaip...
J'ai rebooté sous MacOS9, stuffité les 2 .smi et mis ces 2 archives sur le Bureau de Mac OS 9.
Puis sous Mac OS X renvoyé ces 2 fichiers .sit en ftp avec mon Transmit préféré. Cela doit être OK maintenant.
J'ai noté que si je faisait transiter l'archive par le Desktop de MacOS X, cela introduit également des problèmes, et je les ai donc drag'n droppées directement du dossier "Desktop (Mac OS 9)" vers la fenêtre de Transmit.
-- Sylvain Bouju --
GetNextEvent <void@void.void> wrote:
Pas mieux. OS X a encore frappé :-(
Ouaip...
J'ai rebooté sous MacOS9, stuffité les 2 .smi et
mis ces 2 archives sur le Bureau de Mac OS 9.
Puis sous Mac OS X renvoyé ces 2 fichiers .sit
en ftp avec mon Transmit préféré. Cela doit être
OK maintenant.
J'ai noté que si je faisait transiter l'archive par le
Desktop de MacOS X, cela introduit également
des problèmes, et je les ai donc drag'n droppées
directement du dossier "Desktop (Mac OS 9)" vers
la fenêtre de Transmit.
J'ai rebooté sous MacOS9, stuffité les 2 .smi et mis ces 2 archives sur le Bureau de Mac OS 9.
Puis sous Mac OS X renvoyé ces 2 fichiers .sit en ftp avec mon Transmit préféré. Cela doit être OK maintenant.
J'ai noté que si je faisait transiter l'archive par le Desktop de MacOS X, cela introduit également des problèmes, et je les ai donc drag'n droppées directement du dossier "Desktop (Mac OS 9)" vers la fenêtre de Transmit.
-- Sylvain Bouju --
GetNextEvent
Dans l'article <1gxdhqh.rn0t3rhg5f3iN%, (Sylvain Bouju) écrit:
GetNextEvent wrote:
> Pas mieux. OS X a encore frappé :-(
J'ai rebooté sous MacOS9, stuffité les 2 .smi et mis ces 2 archives sur le Bureau de Mac OS 9.
Et maintenant c'est parfait !
Dans l'article <1gxdhqh.rn0t3rhg5f3iN%syl_vain@bou_ju.net>,
syl_vain@bou_ju.net (Sylvain Bouju) écrit:
GetNextEvent wrote:
> Pas mieux. OS X a encore frappé :-(
J'ai rebooté sous MacOS9, stuffité les 2 .smi et
mis ces 2 archives sur le Bureau de Mac OS 9.
