Mail.app : dites moi qu'ils ont corrigé le bug des fichiers joints !!

Ronnie

Membre actif
7 Août 2000
200
0
J'ai pas encore installé la 10.2.2 (vivement ce soir !
smile.gif
) , mais je me demande vraiment si Apple a corrigé le _BUG_ récurrent depuis la 10.0, qui fait qu'on peut pas envoyer de fichiers joints à des utilisateurs PC par l'intermédiaire de Mail.app.
mad.gif


A priori, au vu du codage 'forcé' utilisé, le possesseur du PC reçoit 2 fichiers identiques (le fichier et le ressource fork ?) et en fonction de son mailer, le fichier de ressource écrase le plus souvent le contenu du fichier...
confused.gif


Etant donné que c'est quand même un désagrément assez génant, pitié, dîtes moi qu'ils l'ont ENFIN corrigé !!

 
C'est curieux ce problème, au travail j'utilise W98 avec Outlook (pas Outlook Express) comme logiciel de mail. Et depuis 10.1.5 je n'ai plus jamais rencontré le problème avec le fichier fork séparé du fichier principal.

Si j'envoies un .jpg, un .mov, ou même un .doc/.xls je ne reçois sur Outlook qu'un seul fichier et c'est le bon. Ah. c'est vrai que au travail j'utilise le PackOffice millenium, je ne sais pas s'il y a un rapport ?? ça pourrait peut-être vous mettre sur la piste ?
 
Bon j'ai fait pas mal de tests entre Mail et Outlook Express...Et résultat : bin ils ont pas corrigé...Je m'explique..

Tout d'abord, sachez que je n'invente rien sur ce problème, vous pourrez trouver sur les forums de Apple des threads interminables là dessus, qui finissent quasiment tous par " Virez Mail - Prenez Entourage ".
mad.gif


Etant donné que j'aime bien Mail, je m'accroche un peu plus
smile.gif


Alors, pour mes tests, d'un côté, OS X.2.2 et donc la dernière version de Mail.. Du côté obscur, un PC sous Win98SE avec Outlook Express 5.

1- Envoi d'une jpeg de 15 ko, sans ressource fork.
==> Réception sans problème, l'image s'affiche même dans la fenêtre de prévisualisation de OE.

2- Envoi d'un fichier PICT de 4ko, avec fork.
==>Réception : aïe aïe aïe
frown.gif
frown.gif

Bon déjà la fenêtre de prévisualisation ne m'affiche pas l'image. Normal, me dis-je, le format PICT doit pas être connu de OE. Je clique donc sur le trombonne pour enregistrer les pièces jointes, et je me retrouve avec 2 FICHIERS de noms identiques. Un qui fait 4 ko, et l'autre qui fait 8 ko. Donc déjà là, le PC-User non averti peut se tromper et enregistrer le mauvais, ou écraser le vrai fichier par le fork (plus gros en plus).

3- Pour en avoir le coeur net, je supprime le ressource fork de ce même fichier et je le renvoie.
==>Réception Nickel..Evidemment pas d'affichage direct sous OE, mais on se retrouve bien avec un seul fichier de 4ko qu'on peut enregistrer sans problème.

4-Encore plus génant. J'envoie cette fois un JPEG, qui normalement doit s'afficher directement dans OE, mais manque de bol, sur mon Mac, ce fichier a un ressource fork. Donc je l'envoie !
==> Réception naze : pas d'affichage de l'image direct, et les deux fichiers homonymes présents dans les pièces jointes.

5- Pour en avoir vraiment le coeur net, je supprime le ressource fork de ce JPEG, je l'envoie et là :
==>Réception normale. OE m'affiche bien l'image directement...

Bon tout ça pour dire que c'est vraiment le fork qui gène, et c'est vraiment dommage qu'Apple traine à régler ce foutu problème qui fait passer les mac-users pour des extra-terrestres pas capables d'envoyer un mail...
laugh.gif
laugh.gif
laugh.gif


Donc en attendant qu'Apple se les sortent, y'a la solution de zipper les documents par sûreté, mais je trouve ça un peu lourd...

J'ai trouvé récemment une solution hyper pratique, rapide, gratuite, et qui à l'air de marcher à tous les coups : ça s'appelle GrimRipper, ça se télécharge ici et ça rajoute un menu contextuel dans OS X, qui permet de supprimer simplement le ressource fork (si le fichier n'en a pas, le menu n'apparait pas)...

Voilà, j'espère que ça aidera...
 
Merci pour ces informations circonstanciées : des tests comme on aimerait en voir plus souvent
laugh.gif


Le pb du deuxième fichier (le resource fork) peut se retrouver aussi bien en réseau (copie findier) qu'avec mail.

C'est pas réellement dramatique mais c'est vrai que pour le pciste lambda, c'est pas de la bonne pub mac. En fait il faut demander à Billou de gérer ça proprement, c'est la moindre des choses, non
laugh.gif
 
A quoi sert-il ce fichier Resource fork ? Et si on le suprime, grace a l'utilitaire mentionné ci-dessus, est-ce genant pour une utilisation mac ?
 
Il me semble que le fork contient des données qui permettent au système de savoir à quel type de fichier il a affaire et de ce fait quelle application permet de l'ouvrir.
Ce système est lié au système de fichier HFS (et HFS+) utilisé par Apple pour les disques.
Par comparaison, Windows utilise l'extention du fichier pour faire la même chose, mais sacrifie du même coup 4 caractères pour nommer les fichiers.
Rien ne permet OBJECTIVEMENT de dire quel système est meilleurs mais une chose est certaine : Apple est le seul "partenaire" informatique (à ma connaissance) a utiliser ce système. Même l'Unix BSD qui sert de base à MacOSX se contrefout de ces forks, qui ne profitent donc qu'au Finder et au applications liées.
Je croit même qu'en fait, MacOS X n'est pas sencé créer ce genre de fichier de ressource.

Voilà,voilà.
zen.gif
 
ça dépend des fichiers :
- pour une application 68000, c'est dans cette fork qu'il y a le code, alors, si tu l'enlèves, ça manque
laugh.gif

Plus généralement, ne pas supprimer pour les applis (mais les applis mac sur PC, à part pour un transfert provisoire, ça ne sert normalemement pas beaucoup).

- pour les documents : les ressources peuvent contenir des polices et des tas d'autres bricoles (préférences, etc.). Dans les applis "modernes", assez souvent, la suppression ne pose pas trop de problèmes.

Le gros intérêt des ressources, plus précisément de leur organisation, pour les applications, était de permettre une séparation propre entre, par exemple, le code d'une appli et les différentes parties interface. En utilisant ResEdit, tu pouvais franciser un logiciel sans toucher au code.

Pour les documents, ça a souvent posé plus de problèmes qu'apporté de réels avantages.