NFS et conversion UTF-8 / UTF-8-MAC, Je deviens fou...
26 réponses
googleg
Bonjour =E0 tous,
J'ai un petit probl=E8me avec la gestion des noms de fichiers d=E8s lors
qu'ils contiennent des accents.
J'ai un serveur Linux (rPath) avec un filesystem r=E9seau que je peux
acc=E9der aussi bien en NFS qu'en SMB. Ce partage est bien s=FBr acc=E9d=E9
par des PC Windows (en SMB) comme par mon Mac (OS X 10.4) en NFS (pour
des questions de performances, le probl=E8me reste le m=EAme si j'acc=E8de
en SMB).
- Si un fichier avec un nom contenant des accents est cr=E9=E9 depuis un
Windows le Mac ne pourra pas l'ouvrir (mais il pourra le voir),
- L'inverse ne pose pas de probl=E8me.
- Pour pouvoir acc=E9der au fichier avec le Mac il me faut changer le
nom du fichier, virer l'accent, et =E9ventuellement le remettre =E0
l'identique, mais depuis le Mac.
Apr=E8s quelques recherches je trouve rapidement la cause de ce probl=E8me
mais malheureusement je n'ai pas pu trouver de solution : le Mac
utilise l'UTF-8-MAC pour encoder le nom des fichiers alors que les PC
Windows (et il semblerait la vaste majorit=E9 des syst=E8mes) utilisent
une version diff=E9rente de l'encodage UTF-8. Si les PC (et le linux)
semblent "flexibles" dans leur gestion des noms, reconnaissant =E0 la
vol=E9e s'il s'agit de l'UTF-8 pr=E9compos=E9 ou d=E9compos=E9, le Mac semb=
le
compl=E8tement rigide...
J'ai d'abord cherch=E9 =E0 changer les choses c=F4t=E9 serveur, par exemple=
en
utilisant le Unix-Charset UTF-8-MAC sur le serveur Samba c=F4t=E9 linux
mais malheureusement cet encodage est inconnu sur mon serveur (pas
pr=E9sent dans le iconv -l). De plus, comme le "fautif" est finalement
le Mac je pense qu'il me faut plut=F4t chercher de ce c=F4t=E9.
La solution consistant =E0 changer tous les noms sur le partage n'est
pas valable car il faudrait le faire =E0 chaque fois qu'un fichier
contenant un accent est cr=E9=E9 par un PC, ce n'est pas jouable.
J'ai essay=E9 de monter le partage NFS sur le mac en passant l'option
iocharset=3Dutf-8 mais =E7a ne donne rien...
Le probl=E8me est connu et en cherchant je peux trouver de nombreux
t=E9moignages sur le net (y compris sur ce groupe), mais je n'ai vu
aucune solution.
À (at) Fri, 28 Nov 2008 14:44:42 -0800 (PST), écrivait (wrote):
Bonjour à tous, J'ai un petit problème avec la gestion des noms de fichiers dès lors qu'ils contiennent des accents.
J'ai un serveur Linux (rPath) avec un filesystem réseau que je peux accéder aussi bien en NFS qu'en SMB. Ce partage est bien sûr accédé par des PC Windows (en SMB) comme par mon Mac (OS X 10.4) en NFS (pour des questions de performances, le problème reste le même si j'accède en SMB).
- Si un fichier avec un nom contenant des accents est créé depuis un Windows le Mac ne pourra pas l'ouvrir (mais il pourra le voir), - L'inverse ne pose pas de problème. - Pour pouvoir accéder au fichier avec le Mac il me faut changer le nom du fichier, virer l'accent, et éventuellement le remettre à l'identique, mais depuis le Mac.
Oui. On a le même problème avec le montage en lecture/écriture des partition NTFS via ntfs-3g.
Après quelques recherches je trouve rapidement la cause de ce problème mais malheureusement je n'ai pas pu trouver de solution : le Mac utilise l'UTF-8-MAC pour encoder le nom des fichiers alors que les PC Windows (et il semblerait la vaste majorité des systèmes) utilisent une version différente de l'encodage UTF-8. Si les PC (et le linux) semblent "flexibles" dans leur gestion des noms, reconnaissant à la volée s'il s'agit de l'UTF-8 précomposé ou décomposé, le Mac semble complètement rigide...
C'est bien la bonne description du problème.
À noter tout de même qu'en passant par la ligne de commande, il n'y a pas de problème : on peut éditer, modifier, copier, renommer tous les fichiers comme on le veut. Le problème est donc dans la sur-couche Apple et pas dans le noyau Darwin.
Est-ce que quelqu'un ici peut m'aider ?
La seule solution est une correction par Apple !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 28 Nov 2008 14:44:42 -0800 (PST),
googleg@ifrance.com écrivait (wrote):
Bonjour à tous,
J'ai un petit problème avec la gestion des noms de fichiers dès lors
qu'ils contiennent des accents.
J'ai un serveur Linux (rPath) avec un filesystem réseau que je peux
accéder aussi bien en NFS qu'en SMB. Ce partage est bien sûr accédé
par des PC Windows (en SMB) comme par mon Mac (OS X 10.4) en NFS (pour
des questions de performances, le problème reste le même si j'accède
en SMB).
- Si un fichier avec un nom contenant des accents est créé depuis un
Windows le Mac ne pourra pas l'ouvrir (mais il pourra le voir),
- L'inverse ne pose pas de problème.
- Pour pouvoir accéder au fichier avec le Mac il me faut changer le
nom du fichier, virer l'accent, et éventuellement le remettre à
l'identique, mais depuis le Mac.
Oui. On a le même problème avec le montage en lecture/écriture des
partition NTFS via ntfs-3g.
Après quelques recherches je trouve rapidement la cause de ce problème
mais malheureusement je n'ai pas pu trouver de solution : le Mac
utilise l'UTF-8-MAC pour encoder le nom des fichiers alors que les PC
Windows (et il semblerait la vaste majorité des systèmes) utilisent
une version différente de l'encodage UTF-8. Si les PC (et le linux)
semblent "flexibles" dans leur gestion des noms, reconnaissant à la
volée s'il s'agit de l'UTF-8 précomposé ou décomposé, le Mac semble
complètement rigide...
C'est bien la bonne description du problème.
À noter tout de même qu'en passant par la ligne de commande, il n'y a
pas de problème : on peut éditer, modifier, copier, renommer tous les
fichiers comme on le veut. Le problème est donc dans la sur-couche
Apple et pas dans le noyau Darwin.
Est-ce que quelqu'un ici peut m'aider ?
La seule solution est une correction par Apple !
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 28 Nov 2008 14:44:42 -0800 (PST), écrivait (wrote):
Bonjour à tous, J'ai un petit problème avec la gestion des noms de fichiers dès lors qu'ils contiennent des accents.
J'ai un serveur Linux (rPath) avec un filesystem réseau que je peux accéder aussi bien en NFS qu'en SMB. Ce partage est bien sûr accédé par des PC Windows (en SMB) comme par mon Mac (OS X 10.4) en NFS (pour des questions de performances, le problème reste le même si j'accède en SMB).
- Si un fichier avec un nom contenant des accents est créé depuis un Windows le Mac ne pourra pas l'ouvrir (mais il pourra le voir), - L'inverse ne pose pas de problème. - Pour pouvoir accéder au fichier avec le Mac il me faut changer le nom du fichier, virer l'accent, et éventuellement le remettre à l'identique, mais depuis le Mac.
Oui. On a le même problème avec le montage en lecture/écriture des partition NTFS via ntfs-3g.
Après quelques recherches je trouve rapidement la cause de ce problème mais malheureusement je n'ai pas pu trouver de solution : le Mac utilise l'UTF-8-MAC pour encoder le nom des fichiers alors que les PC Windows (et il semblerait la vaste majorité des systèmes) utilisent une version différente de l'encodage UTF-8. Si les PC (et le linux) semblent "flexibles" dans leur gestion des noms, reconnaissant à la volée s'il s'agit de l'UTF-8 précomposé ou décomposé, le Mac semble complètement rigide...
C'est bien la bonne description du problème.
À noter tout de même qu'en passant par la ligne de commande, il n'y a pas de problème : on peut éditer, modifier, copier, renommer tous les fichiers comme on le veut. Le problème est donc dans la sur-couche Apple et pas dans le noyau Darwin.
Est-ce que quelqu'un ici peut m'aider ?
La seule solution est une correction par Apple !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
blanc
wrote:
Est-ce que quelqu'un ici peut m'aider ?
Tu as, je pense, des choses intéressantes qui ont été dites ici même : <http://groups.google.com/group/fr.comp.os.mac-os.x/search?group=fr.comp .os.mac-os.x&q=leopard+nfs&qt_g=Rechercher+dans+ce+groupe>
avec référence à cette page <http://unicode.org/reports/tr15/>
Autres pages intéressantes chez Apple : <http://developer.apple.com/qa/qa2001/qa1235.html>
et sur wikipedia (English) : <http://en.wikipedia.org/wiki/Unicode_normalization>
Ensuite. Pourquoi Apple n'est pas capable de lire les formes utilisées sous win ou linux, je ne sais pas. Et ne sais pas non plus comment contourner ce pb. -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
<googleg@ifrance.com> wrote:
Est-ce que quelqu'un ici peut m'aider ?
Tu as, je pense, des choses intéressantes qui ont été dites ici même :
<http://groups.google.com/group/fr.comp.os.mac-os.x/search?group=fr.comp
.os.mac-os.x&q=leopard+nfs&qt_g=Rechercher+dans+ce+groupe>
avec référence à cette page
<http://unicode.org/reports/tr15/>
Autres pages intéressantes chez Apple :
<http://developer.apple.com/qa/qa2001/qa1235.html>
et sur wikipedia (English) :
<http://en.wikipedia.org/wiki/Unicode_normalization>
Ensuite. Pourquoi Apple n'est pas capable de lire les formes utilisées
sous win ou linux, je ne sais pas. Et ne sais pas non plus comment
contourner ce pb.
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Tu as, je pense, des choses intéressantes qui ont été dites ici même : <http://groups.google.com/group/fr.comp.os.mac-os.x/search?group=fr.comp .os.mac-os.x&q=leopard+nfs&qt_g=Rechercher+dans+ce+groupe>
avec référence à cette page <http://unicode.org/reports/tr15/>
Autres pages intéressantes chez Apple : <http://developer.apple.com/qa/qa2001/qa1235.html>
et sur wikipedia (English) : <http://en.wikipedia.org/wiki/Unicode_normalization>
Ensuite. Pourquoi Apple n'est pas capable de lire les formes utilisées sous win ou linux, je ne sais pas. Et ne sais pas non plus comment contourner ce pb. -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
googleg
On 30 nov, 16:16, Paul Gaborit wrote:
Oui. On a le même problème avec le montage en lecture/écriture des partition NTFS via ntfs-3g.
[...]
Le problème est donc dans la sur-couche Apple et pas dans le noyau Darwin.
[...]
La seule solution est une correction par Apple !
J'avais espéré qu'il y ait une autre solution, les messages étant dan s l'ensemble assez vieux, je me disais que certains avaient trouvé. A noter que rsync comprend une option --iconv bien utile pour ce problème... Ne serait-il pas envisageable de compiler des outils qui vont bien ?
On 30 nov, 16:16, Paul Gaborit <Paul.Gabo...@invalid.invalid> wrote:
Oui. On a le même problème avec le montage en lecture/écriture des
partition NTFS via ntfs-3g.
[...]
Le problème est donc dans la sur-couche
Apple et pas dans le noyau Darwin.
[...]
La seule solution est une correction par Apple !
J'avais espéré qu'il y ait une autre solution, les messages étant dan s
l'ensemble assez vieux, je me disais que certains avaient trouvé. A
noter que rsync comprend une option --iconv bien utile pour ce
problème... Ne serait-il pas envisageable de compiler des outils qui
vont bien ?
Oui. On a le même problème avec le montage en lecture/écriture des partition NTFS via ntfs-3g.
[...]
Le problème est donc dans la sur-couche Apple et pas dans le noyau Darwin.
[...]
La seule solution est une correction par Apple !
J'avais espéré qu'il y ait une autre solution, les messages étant dan s l'ensemble assez vieux, je me disais que certains avaient trouvé. A noter que rsync comprend une option --iconv bien utile pour ce problème... Ne serait-il pas envisageable de compiler des outils qui vont bien ?
blanc
JiPaul wrote:
et sur wikipedia (English) : <http://en.wikipedia.org/wiki/Unicode_normalization>
Je me suis d'ailleurs lancé dans la traduction de ce texte, histoire de mieux comprendre... :-) <http://fr.wikipedia.org/wiki/Equivalences_unicode> -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
JiPaul <blanc@empty.org> wrote:
et sur wikipedia (English) :
<http://en.wikipedia.org/wiki/Unicode_normalization>
Je me suis d'ailleurs lancé dans la traduction de ce texte, histoire de
mieux comprendre... :-)
<http://fr.wikipedia.org/wiki/Equivalences_unicode>
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
et sur wikipedia (English) : <http://en.wikipedia.org/wiki/Unicode_normalization>
Je me suis d'ailleurs lancé dans la traduction de ce texte, histoire de mieux comprendre... :-) <http://fr.wikipedia.org/wiki/Equivalences_unicode> -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
blanc
JiPaul wrote:
Je me suis d'ailleurs lancé dans la traduction de ce texte, histoire de mieux comprendre... :-)
Et j'ai trouvé, en français, le texte suivant, qui a l'air beaucoup plus précis : <http://hapax.qc.ca/pdf/Chapitre-6.pdf> -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
JiPaul <blanc@empty.org> wrote:
Je me suis d'ailleurs lancé dans la traduction de ce texte, histoire de
mieux comprendre... :-)
Et j'ai trouvé, en français, le texte suivant, qui a l'air beaucoup plus
précis :
<http://hapax.qc.ca/pdf/Chapitre-6.pdf>
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Je me suis d'ailleurs lancé dans la traduction de ce texte, histoire de mieux comprendre... :-)
Et j'ai trouvé, en français, le texte suivant, qui a l'air beaucoup plus précis : <http://hapax.qc.ca/pdf/Chapitre-6.pdf> -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
blanc
wrote:
Après quelques recherches je trouve rapidement la cause de ce problème mais malheureusement je n'ai pas pu trouver de solution : le Mac utilise l'UTF-8-MAC pour encoder le nom des fichiers alors que les PC Windows (et il semblerait la vaste majorité des systèmes) utilisent une version différente de l'encodage UTF-8. Si les PC (et le linux) semblent "flexibles" dans leur gestion des noms, reconnaissant à la volée s'il s'agit de l'UTF-8 précomposé ou décomposé, le Mac semble complètement rigide...
Après avoir lu en grande partie ce texte : <http://hapax.qc.ca/pdf/Chapitre-6.pdf>
et traduit celui de Wikipedia : <http://fr.wikipedia.org/wiki/Equivalences_unicode>
je me permet de reformuler ta présentation du problème : Il n'y a qu'un bien qu'un seul UTF-8 (manière de coder l'Unicode par multi-octets) mais il y a plusieurs manières de représenter un même caractère accentué dans l'Unicode : - soit sous forme composée. Exemple : ñ - soit sous forme décomposée. Exemple : n + ~
Ceci pour des raisons de compatibilités avec les autres systèmes de codages que Unicode. Pour permettre des comparaisons, tris, recherches, il existe quatre formes normales. Peu importe sous quelle forme (composée ou décomposée) sont stockés les noms de fichiers. Normalement le Mac (ou plutôt NFS dans Mac) devrait commencer par traduire dans la forme normale qu'il utilise. Apparemment il ne le fait pas (ou il le fait mal) alors que win ou linux le font bien (c'est en cela qu'ils sont plus "flexibles"). Donc amha c'est bien un problème que devrait corriger Apple (ou plus précisément ceux qui ont conçu l'interface NFS chez Apple), et il faudrait peut-être qu'on fasse une remontée de bug. :-/
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
<googleg@ifrance.com> wrote:
Après quelques recherches je trouve rapidement la cause de ce problème
mais malheureusement je n'ai pas pu trouver de solution : le Mac
utilise l'UTF-8-MAC pour encoder le nom des fichiers alors que les PC
Windows (et il semblerait la vaste majorité des systèmes) utilisent
une version différente de l'encodage UTF-8. Si les PC (et le linux)
semblent "flexibles" dans leur gestion des noms, reconnaissant à la
volée s'il s'agit de l'UTF-8 précomposé ou décomposé, le Mac semble
complètement rigide...
Après avoir lu en grande partie ce texte :
<http://hapax.qc.ca/pdf/Chapitre-6.pdf>
et traduit celui de Wikipedia :
<http://fr.wikipedia.org/wiki/Equivalences_unicode>
je me permet de reformuler ta présentation du problème :
Il n'y a qu'un bien qu'un seul UTF-8 (manière de coder l'Unicode par
multi-octets) mais il y a plusieurs manières de représenter un même
caractère accentué dans l'Unicode :
- soit sous forme composée. Exemple : ñ
- soit sous forme décomposée. Exemple : n + ~
Ceci pour des raisons de compatibilités avec les autres systèmes de
codages que Unicode.
Pour permettre des comparaisons, tris, recherches, il existe quatre
formes normales. Peu importe sous quelle forme (composée ou décomposée)
sont stockés les noms de fichiers. Normalement le Mac (ou plutôt NFS
dans Mac) devrait commencer par traduire dans la forme normale qu'il
utilise. Apparemment il ne le fait pas (ou il le fait mal) alors que win
ou linux le font bien (c'est en cela qu'ils sont plus "flexibles"). Donc
amha c'est bien un problème que devrait corriger Apple (ou plus
précisément ceux qui ont conçu l'interface NFS chez Apple), et il
faudrait peut-être qu'on fasse une remontée de bug. :-/
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Après quelques recherches je trouve rapidement la cause de ce problème mais malheureusement je n'ai pas pu trouver de solution : le Mac utilise l'UTF-8-MAC pour encoder le nom des fichiers alors que les PC Windows (et il semblerait la vaste majorité des systèmes) utilisent une version différente de l'encodage UTF-8. Si les PC (et le linux) semblent "flexibles" dans leur gestion des noms, reconnaissant à la volée s'il s'agit de l'UTF-8 précomposé ou décomposé, le Mac semble complètement rigide...
Après avoir lu en grande partie ce texte : <http://hapax.qc.ca/pdf/Chapitre-6.pdf>
et traduit celui de Wikipedia : <http://fr.wikipedia.org/wiki/Equivalences_unicode>
je me permet de reformuler ta présentation du problème : Il n'y a qu'un bien qu'un seul UTF-8 (manière de coder l'Unicode par multi-octets) mais il y a plusieurs manières de représenter un même caractère accentué dans l'Unicode : - soit sous forme composée. Exemple : ñ - soit sous forme décomposée. Exemple : n + ~
Ceci pour des raisons de compatibilités avec les autres systèmes de codages que Unicode. Pour permettre des comparaisons, tris, recherches, il existe quatre formes normales. Peu importe sous quelle forme (composée ou décomposée) sont stockés les noms de fichiers. Normalement le Mac (ou plutôt NFS dans Mac) devrait commencer par traduire dans la forme normale qu'il utilise. Apparemment il ne le fait pas (ou il le fait mal) alors que win ou linux le font bien (c'est en cela qu'ils sont plus "flexibles"). Donc amha c'est bien un problème que devrait corriger Apple (ou plus précisément ceux qui ont conçu l'interface NFS chez Apple), et il faudrait peut-être qu'on fasse une remontée de bug. :-/
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
googleg
On 1 déc, 18:05, (JiPaul) wrote:
Donc amha c'est bien un problème que devrait corriger Apple (ou plus précisément ceux qui ont conçu l'interface NFS chez Apple), et il faudrait peut-être qu'on fasse une remontée de bug. :-/
Ca serait l'idéal, maintenant est-ce réalisable... Faudrait voir comment ouvrir un rapport de bug sur le site apple...
On 1 déc, 18:05, bl...@empty.org (JiPaul) wrote:
Donc
amha c'est bien un problème que devrait corriger Apple (ou plus
précisément ceux qui ont conçu l'interface NFS chez Apple), et il
faudrait peut-être qu'on fasse une remontée de bug. :-/
Ca serait l'idéal, maintenant est-ce réalisable... Faudrait voir
comment ouvrir un rapport de bug sur le site apple...
Donc amha c'est bien un problème que devrait corriger Apple (ou plus précisément ceux qui ont conçu l'interface NFS chez Apple), et il faudrait peut-être qu'on fasse une remontée de bug. :-/
Ca serait l'idéal, maintenant est-ce réalisable... Faudrait voir comment ouvrir un rapport de bug sur le site apple...
blanc
wrote:
Ca serait l'idéal, maintenant est-ce réalisable... Faudrait voir comment ouvrir un rapport de bug sur le site apple...
http://www.apple.com/feedback/ -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
<googleg@ifrance.com> wrote:
Ca serait l'idéal, maintenant est-ce réalisable... Faudrait voir
comment ouvrir un rapport de bug sur le site apple...
http://www.apple.com/feedback/
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Ca serait l'idéal, maintenant est-ce réalisable... Faudrait voir comment ouvrir un rapport de bug sur le site apple...
http://www.apple.com/feedback/ -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Eric Levenez
Le 01/12/08 23:35, dans <1iramuq.1bxd79g12o8tfkN%, « JiPaul » a écrit :
wrote:
Ca serait l'idéal, maintenant est-ce réalisable... Faudrait voir comment ouvrir un rapport de bug sur le site apple...
http://www.apple.com/feedback/
Le mieux étant <https://bugreport.apple.com/> avec un compte ADC (qui peut être gratuit).
Rappel : plus il y a de bug reports pour un bug donné, plus celui-ci a des chances d'être corrigé, et il ne faut pas croire que "les autres" feront le bug report à notre place.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 01/12/08 23:35, dans <1iramuq.1bxd79g12o8tfkN%blanc@empty.org>,
« JiPaul » <blanc@empty.org> a écrit :
<googleg@ifrance.com> wrote:
Ca serait l'idéal, maintenant est-ce réalisable... Faudrait voir
comment ouvrir un rapport de bug sur le site apple...
http://www.apple.com/feedback/
Le mieux étant <https://bugreport.apple.com/> avec un compte ADC (qui peut
être gratuit).
Rappel : plus il y a de bug reports pour un bug donné, plus celui-ci a des
chances d'être corrigé, et il ne faut pas croire que "les autres" feront le
bug report à notre place.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 01/12/08 23:35, dans <1iramuq.1bxd79g12o8tfkN%, « JiPaul » a écrit :
wrote:
Ca serait l'idéal, maintenant est-ce réalisable... Faudrait voir comment ouvrir un rapport de bug sur le site apple...
http://www.apple.com/feedback/
Le mieux étant <https://bugreport.apple.com/> avec un compte ADC (qui peut être gratuit).
Rappel : plus il y a de bug reports pour un bug donné, plus celui-ci a des chances d'être corrigé, et il ne faut pas croire que "les autres" feront le bug report à notre place.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
googleg
On 1 déc, 23:44, Eric Levenez wrote:
Le mieux étant <https://bugreport.apple.com/> avec un compte ADC (qui p eut être gratuit).
Bon, je viens de m'inscrire et de faire mon rapport de bug !
J'ai un peu l'impression de pleurer dans un violon mais sait-on jamais... Je suis encore jeune, peut-être que le bug sera corrigé avant ma mort.
On 1 déc, 23:44, Eric Levenez <use...@levenez.com> wrote:
Le mieux étant <https://bugreport.apple.com/> avec un compte ADC (qui p eut
être gratuit).
Bon, je viens de m'inscrire et de faire mon rapport de bug !
J'ai un peu l'impression de pleurer dans un violon mais sait-on
jamais... Je suis encore jeune, peut-être que le bug sera corrigé
avant ma mort.
