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) Mon, 1 Dec 2008 18:05:41 +0100, (JiPaul) écrivait (wrote): [... plein de trucs sur UTF-8 et les caractères composés...]
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. :-/
Je rappelle que cela n'a rien de spécifique à NFS. Le système Unix sous-jacent à MacOS X (disons Darwin) gère parfaitement les fichiers avec accents qu'ils viennent de NFS, d'un NTFS ou d'un autre file system utilisant l'encodage UTF-8 (avec les différentes variantes de compostion des caractères).
Le problème vient de la couche au-dessus d'Unix qui fait toute l'interface graphique (je ne sais pas si le terme 'Aqua' recouvre vraiment tout). C'est cette couche qui ne gère qu'une seule manière de composer les caractères UTF-8 (et pas celle utilisée en standard par Linux et Windows) ! Donc toutes les applications purement graphiques (le Finder en premier) sont touchées par ce bug/défaut !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 1 Dec 2008 18:05:41 +0100,
blanc@empty.org (JiPaul) écrivait (wrote):
[... plein de trucs sur UTF-8 et les caractères composés...]
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. :-/
Je rappelle que cela n'a rien de spécifique à NFS. Le système Unix
sous-jacent à MacOS X (disons Darwin) gère parfaitement les fichiers
avec accents qu'ils viennent de NFS, d'un NTFS ou d'un autre file
system utilisant l'encodage UTF-8 (avec les différentes variantes de
compostion des caractères).
Le problème vient de la couche au-dessus d'Unix qui fait toute
l'interface graphique (je ne sais pas si le terme 'Aqua' recouvre
vraiment tout). C'est cette couche qui ne gère qu'une seule manière de
composer les caractères UTF-8 (et pas celle utilisée en standard par
Linux et Windows) ! Donc toutes les applications purement graphiques
(le Finder en premier) sont touchées par ce bug/défaut !
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 1 Dec 2008 18:05:41 +0100, (JiPaul) écrivait (wrote): [... plein de trucs sur UTF-8 et les caractères composés...]
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. :-/
Je rappelle que cela n'a rien de spécifique à NFS. Le système Unix sous-jacent à MacOS X (disons Darwin) gère parfaitement les fichiers avec accents qu'ils viennent de NFS, d'un NTFS ou d'un autre file system utilisant l'encodage UTF-8 (avec les différentes variantes de compostion des caractères).
Le problème vient de la couche au-dessus d'Unix qui fait toute l'interface graphique (je ne sais pas si le terme 'Aqua' recouvre vraiment tout). C'est cette couche qui ne gère qu'une seule manière de composer les caractères UTF-8 (et pas celle utilisée en standard par Linux et Windows) ! Donc toutes les applications purement graphiques (le Finder en premier) sont touchées par ce bug/défaut !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
googleg
On 2 déc, 16:43, Paul Gaborit wrote:
Je rappelle que cela n'a rien de spécifique à NFS.
J'avoue ne pas avoir les idées bien claires sur le problème mais j'ai mené des tests et le(s) résultat(s) me laissent pensif.
Soit A le fait de créer un répertoire avec des accents dans le nom, y placer une image .jpg, le tout depuis une machine non-OSX, Soit B le fait d'ouvrir le fichier .jpg depuis le Finder de mon Mac OS X,
Je teste en montant la même partition sous Linux, Windows (XP) et Mac OSX, aussi bien en SMB/CIFS qu'en NFS...
Si je fais A depuis un windows en SMB et je fais B en Samba -> Non OK Si je fais A depuis un windows en NFS et je fais B en Samba -> Non OK Si je fais A depuis un windows en SMB et je fais B en NFS -> Non OK Si je fais A depuis un windows en NFS et je fais B en NFS -> Non OK Si je fais A depuis un linux en SMB et je fais B en NFS -> Non OK Si je fais A depuis un linux en NFS et je fais B en NFS -> OK
Je pourrais encore détailler, car suivant les cas j'ai, depuis OS X, des comportements différents, parfois je peux lire le nom du répertoire (il s'affiche correctement), parfois les accents apparaissent comme des caractères bizarres, et dans le pire des cas le répertoire dont le nom comporte des accents n'apparait même pas dans la fenêtre du Finder !!!
Bref, tout ce là est très drôle et je suis très... désapointé, le seul cas qui marche correctement est la création du répertoire avec accents depuis un Linux en NFS et le montage sous Mac OSX en Samba. Je rappelle que dans tous les cas l'inverse fonctionne (sauf que le montage NFS sous windows ne supporte pas les accents créés depuis le Mac, mais bon, le client NFS pour Windows est vraiment moisi donc je ne m'inquiète pas trop).
Or moi ce que je veux c'est un support NFS sur Mac qui marche, premièrement parce que ça m'écorche le nez de me rabbattre sur SMB sous Mac OSX, et deuxièmement parce que sur mon réseau NFS tatanne deux fois plus que SMB pour transférer des données (typiquement des photos) !!
Malgré tout je suis content de voir que je ne suis pas seul à me débattre dans les limbes de l'OS X, pauvres damnés que nous sommes...
On 2 déc, 16:43, Paul Gaborit <Paul.Gabo...@invalid.invalid> wrote:
Je rappelle que cela n'a rien de spécifique à NFS.
J'avoue ne pas avoir les idées bien claires sur le problème mais j'ai
mené des tests et le(s) résultat(s) me laissent pensif.
Soit A le fait de créer un répertoire avec des accents dans le nom, y
placer une image .jpg, le tout depuis une machine non-OSX,
Soit B le fait d'ouvrir le fichier .jpg depuis le Finder de mon Mac OS
X,
Je teste en montant la même partition sous Linux, Windows (XP) et Mac
OSX, aussi bien en SMB/CIFS qu'en NFS...
Si je fais A depuis un windows en SMB et je fais B en Samba -> Non OK
Si je fais A depuis un windows en NFS et je fais B en Samba -> Non OK
Si je fais A depuis un windows en SMB et je fais B en NFS -> Non OK
Si je fais A depuis un windows en NFS et je fais B en NFS -> Non OK
Si je fais A depuis un linux en SMB et je fais B en NFS -> Non OK
Si je fais A depuis un linux en NFS et je fais B en NFS -> OK
Je pourrais encore détailler, car suivant les cas j'ai, depuis OS X,
des comportements différents, parfois je peux lire le nom du
répertoire (il s'affiche correctement), parfois les accents
apparaissent comme des caractères bizarres, et dans le pire des cas le
répertoire dont le nom comporte des accents n'apparait même pas dans
la fenêtre du Finder !!!
Bref, tout ce là est très drôle et je suis très... désapointé, le seul
cas qui marche correctement est la création du répertoire avec accents
depuis un Linux en NFS et le montage sous Mac OSX en Samba. Je
rappelle que dans tous les cas l'inverse fonctionne (sauf que le
montage NFS sous windows ne supporte pas les accents créés depuis le
Mac, mais bon, le client NFS pour Windows est vraiment moisi donc je
ne m'inquiète pas trop).
Or moi ce que je veux c'est un support NFS sur Mac qui marche,
premièrement parce que ça m'écorche le nez de me rabbattre sur SMB
sous Mac OSX, et deuxièmement parce que sur mon réseau NFS tatanne
deux fois plus que SMB pour transférer des données (typiquement des
photos) !!
Malgré tout je suis content de voir que je ne suis pas seul à me
débattre dans les limbes de l'OS X, pauvres damnés que nous sommes...
Je rappelle que cela n'a rien de spécifique à NFS.
J'avoue ne pas avoir les idées bien claires sur le problème mais j'ai mené des tests et le(s) résultat(s) me laissent pensif.
Soit A le fait de créer un répertoire avec des accents dans le nom, y placer une image .jpg, le tout depuis une machine non-OSX, Soit B le fait d'ouvrir le fichier .jpg depuis le Finder de mon Mac OS X,
Je teste en montant la même partition sous Linux, Windows (XP) et Mac OSX, aussi bien en SMB/CIFS qu'en NFS...
Si je fais A depuis un windows en SMB et je fais B en Samba -> Non OK Si je fais A depuis un windows en NFS et je fais B en Samba -> Non OK Si je fais A depuis un windows en SMB et je fais B en NFS -> Non OK Si je fais A depuis un windows en NFS et je fais B en NFS -> Non OK Si je fais A depuis un linux en SMB et je fais B en NFS -> Non OK Si je fais A depuis un linux en NFS et je fais B en NFS -> OK
Je pourrais encore détailler, car suivant les cas j'ai, depuis OS X, des comportements différents, parfois je peux lire le nom du répertoire (il s'affiche correctement), parfois les accents apparaissent comme des caractères bizarres, et dans le pire des cas le répertoire dont le nom comporte des accents n'apparait même pas dans la fenêtre du Finder !!!
Bref, tout ce là est très drôle et je suis très... désapointé, le seul cas qui marche correctement est la création du répertoire avec accents depuis un Linux en NFS et le montage sous Mac OSX en Samba. Je rappelle que dans tous les cas l'inverse fonctionne (sauf que le montage NFS sous windows ne supporte pas les accents créés depuis le Mac, mais bon, le client NFS pour Windows est vraiment moisi donc je ne m'inquiète pas trop).
Or moi ce que je veux c'est un support NFS sur Mac qui marche, premièrement parce que ça m'écorche le nez de me rabbattre sur SMB sous Mac OSX, et deuxièmement parce que sur mon réseau NFS tatanne deux fois plus que SMB pour transférer des données (typiquement des photos) !!
Malgré tout je suis content de voir que je ne suis pas seul à me débattre dans les limbes de l'OS X, pauvres damnés que nous sommes...
googleg
On 2 déc, 17:19, wrote:
Si je fais A depuis un linux en NFS et je fais B en NFS -> OK
Correction:
Si je fais A depuis un linux en NFS et je fais B en Samba -> OK
On 2 déc, 17:19, goog...@ifrance.com wrote:
Si je fais A depuis un linux en NFS et je fais B en NFS -> OK
Correction:
Si je fais A depuis un linux en NFS et je fais B en Samba -> OK
Si je fais A depuis un linux en NFS et je fais B en NFS -> OK
Correction:
Si je fais A depuis un linux en NFS et je fais B en Samba -> OK
FiLH
(JiPaul) writes:
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...
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. :-/
Il y a surtout un pb très amusant : - le Mac lit très bien les utf non mac. - le Mac par contre va écrire un fichier de metadata sur nfs... et c'est là que les ennuis commencent... car le fichier de metadata est écrit avec le codage Mac ! On se retrouve donc dans la situation suivante : le fichier et ses métadatas n'ont pas un nom identique octet par octet. Et là... ben le finder il ne sait pas faire, et donc le double clic open ne marche pas parce que le finder cherche les metadatas, ne les trouves pas, les crée (je pense), ne les trouve toujours pas...
J'avais eu le pb effectivement en passant d'un share appletalk à un share nfs.
Une solution pour notre ami googleg serait peut-être d'utiliser netatalk qui ne marche pas trop mal.
Sinon.. ben trouver un recode ou un iconv qui parle utf8-mac et faire une moulinette pour renomer les fichiers...
Il semble hélas que nfs ne soit pas une préoccupation majeure chez Apple, malgrés la mise en place d'autofs... peut-Être que si jamais ils passaient à zfs ils mettraient un peu les choses à plat ?
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
blanc@empty.org (JiPaul) writes:
<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...
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. :-/
Il y a surtout un pb très amusant :
- le Mac lit très bien les utf non mac.
- le Mac par contre va écrire un fichier de metadata sur nfs... et
c'est là que les ennuis commencent... car le fichier de metadata est
écrit avec le codage Mac !
On se retrouve donc dans la situation suivante : le fichier et ses
métadatas n'ont pas un nom identique octet par octet.
Et là... ben le finder il ne sait pas faire, et donc le double clic
open ne marche pas parce que le finder cherche les metadatas, ne les
trouves pas, les crée (je pense), ne les trouve toujours pas...
J'avais eu le pb effectivement en passant d'un share appletalk à un
share nfs.
Une solution pour notre ami googleg serait peut-être d'utiliser
netatalk qui ne marche pas trop mal.
Sinon.. ben trouver un recode ou un iconv qui parle utf8-mac et faire
une moulinette pour renomer les fichiers...
Il semble hélas que nfs ne soit pas une préoccupation majeure chez
Apple, malgrés la mise en place d'autofs... peut-Être que si jamais
ils passaient à zfs ils mettraient un peu les choses à plat ?
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
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...
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. :-/
Il y a surtout un pb très amusant : - le Mac lit très bien les utf non mac. - le Mac par contre va écrire un fichier de metadata sur nfs... et c'est là que les ennuis commencent... car le fichier de metadata est écrit avec le codage Mac ! On se retrouve donc dans la situation suivante : le fichier et ses métadatas n'ont pas un nom identique octet par octet. Et là... ben le finder il ne sait pas faire, et donc le double clic open ne marche pas parce que le finder cherche les metadatas, ne les trouves pas, les crée (je pense), ne les trouve toujours pas...
J'avais eu le pb effectivement en passant d'un share appletalk à un share nfs.
Une solution pour notre ami googleg serait peut-être d'utiliser netatalk qui ne marche pas trop mal.
Sinon.. ben trouver un recode ou un iconv qui parle utf8-mac et faire une moulinette pour renomer les fichiers...
Il semble hélas que nfs ne soit pas une préoccupation majeure chez Apple, malgrés la mise en place d'autofs... peut-Être que si jamais ils passaient à zfs ils mettraient un peu les choses à plat ?
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Erwan David
Paul Gaborit écrivait :
Le problème vient de la couche au-dessus d'Unix qui fait toute l'interface graphique (je ne sais pas si le terme 'Aqua' recouvre vraiment tout). C'est cette couche qui ne gère qu'une seule manière de composer les caractères UTF-8 (et pas celle utilisée en standard par Linux et Windows) ! Donc toutes les applications purement graphiques (le Finder en premier) sont touchées par ce bug/défaut !
Notos que les RFC conseillet d'utiiser la forme composée et non la forme décomposée pour les échanges réseau. Donc il faut s'atendre à devoir traiter du composé.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait :
Le problème vient de la couche au-dessus d'Unix qui fait toute
l'interface graphique (je ne sais pas si le terme 'Aqua' recouvre
vraiment tout). C'est cette couche qui ne gère qu'une seule manière de
composer les caractères UTF-8 (et pas celle utilisée en standard par
Linux et Windows) ! Donc toutes les applications purement graphiques
(le Finder en premier) sont touchées par ce bug/défaut !
Notos que les RFC conseillet d'utiiser la forme composée et non la forme
décomposée pour les échanges réseau. Donc il faut s'atendre à devoir
traiter du composé.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Le problème vient de la couche au-dessus d'Unix qui fait toute l'interface graphique (je ne sais pas si le terme 'Aqua' recouvre vraiment tout). C'est cette couche qui ne gère qu'une seule manière de composer les caractères UTF-8 (et pas celle utilisée en standard par Linux et Windows) ! Donc toutes les applications purement graphiques (le Finder en premier) sont touchées par ce bug/défaut !
Notos que les RFC conseillet d'utiiser la forme composée et non la forme décomposée pour les échanges réseau. Donc il faut s'atendre à devoir traiter du composé.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
googleg
Bon, re-correction, en fait en Samba tout marche contrairement à ce que j'ai dit...
Si je fais A depuis un windows en NFS et je fais B en Samba -> Non OK Si je fais A depuis un windows en SMB et je fais B en NFS -> Non OK Si je fais A depuis un windows en NFS et je fais B en NFS -> Non OK Si je fais A depuis un linux en SMB et je fais B en NFS -> Non OK Si je fais A depuis un linux en NFS et je fais B en Samba -> OK Si je fais A depuis un windows en SMB et je fais B en Samba -> OK Si je fais A depuis un linux en SMB et je fais B en Samba -> OK
Sinon Netatlk bonne idée, sauf que dans mon cas je travaille avec un NAS Openfiler, et qu'il n'y a pas de package Netatalk tout prêt, je vais devoir me lancer dans la compil, ce qui prendra du temps (je dois faire ça sur un système de test).
Une autre option serait d'utiliser iSCSI, à creuser...
Bon, re-correction, en fait en Samba tout marche contrairement à ce
que j'ai dit...
Si je fais A depuis un windows en NFS et je fais B en Samba -> Non OK
Si je fais A depuis un windows en SMB et je fais B en NFS -> Non OK
Si je fais A depuis un windows en NFS et je fais B en NFS -> Non OK
Si je fais A depuis un linux en SMB et je fais B en NFS -> Non OK
Si je fais A depuis un linux en NFS et je fais B en Samba -> OK
Si je fais A depuis un windows en SMB et je fais B en Samba -> OK
Si je fais A depuis un linux en SMB et je fais B en Samba -> OK
Sinon Netatlk bonne idée, sauf que dans mon cas je travaille avec un
NAS Openfiler, et qu'il n'y a pas de package Netatalk tout prêt, je
vais devoir me lancer dans la compil, ce qui prendra du temps (je dois
faire ça sur un système de test).
Une autre option serait d'utiliser iSCSI, à creuser...
Bon, re-correction, en fait en Samba tout marche contrairement à ce que j'ai dit...
Si je fais A depuis un windows en NFS et je fais B en Samba -> Non OK Si je fais A depuis un windows en SMB et je fais B en NFS -> Non OK Si je fais A depuis un windows en NFS et je fais B en NFS -> Non OK Si je fais A depuis un linux en SMB et je fais B en NFS -> Non OK Si je fais A depuis un linux en NFS et je fais B en Samba -> OK Si je fais A depuis un windows en SMB et je fais B en Samba -> OK Si je fais A depuis un linux en SMB et je fais B en Samba -> OK
Sinon Netatlk bonne idée, sauf que dans mon cas je travaille avec un NAS Openfiler, et qu'il n'y a pas de package Netatalk tout prêt, je vais devoir me lancer dans la compil, ce qui prendra du temps (je dois faire ça sur un système de test).
Une autre option serait d'utiliser iSCSI, à creuser...
Pucud
Eric Levenez wrote:
.../...
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.
Le pb est d'avoir un niveau de compétence suffisant pour que le report soit pris en considération. Je subis ce pb, mais .... voir ci-dessus! ** cix ** Alors je suis reconnaissant à tous ceux qui contribuent à l'élimination des bugs...
Eric Levenez wrote:
.../...
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.
Le pb est d'avoir un niveau de compétence suffisant pour que le report
soit pris en considération.
Je subis ce pb, mais .... voir ci-dessus!
** cix **
Alors je suis reconnaissant à tous ceux qui contribuent à l'élimination
des bugs...
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.
Le pb est d'avoir un niveau de compétence suffisant pour que le report soit pris en considération. Je subis ce pb, mais .... voir ci-dessus! ** cix ** Alors je suis reconnaissant à tous ceux qui contribuent à l'élimination des bugs...
googleg
On 2 déc, 13:31, wrote:
Bon, je viens de m'inscrire et de faire mon rapport de bug !
Hourra, je viens d'avoir une réponse d'Apole à mon rapport de bug (en 8 jours, pas mal)... Je cite (même si il y a un avertissement de non- disclosure) :
"After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering. This issue has been filed in our bug database under the original Bug ID# 2968675. The original bug number being used to track this duplicate issue can be found in the State column, in this format: Duplicate/OrigBug#.
Thank you for submitting this bug report. We truly appreciate your assistance in helping us discover and isolate bugs."
Bon, heu, au moins ils sont au courant, et on est au moins 2 à avoir rapporté le même bug !
On 2 déc, 13:31, goog...@ifrance.com wrote:
Bon, je viens de m'inscrire et de faire mon rapport de bug !
Hourra, je viens d'avoir une réponse d'Apole à mon rapport de bug (en
8 jours, pas mal)... Je cite (même si il y a un avertissement de non-
disclosure) :
"After further investigation it has been determined that this is a
known issue, which is currently being investigated by engineering.
This issue has been filed in our bug database under the original Bug
ID# 2968675. The original bug number being used to track this
duplicate issue can be found in the State column, in this format:
Duplicate/OrigBug#.
Thank you for submitting this bug report. We truly appreciate your
assistance in helping us discover and isolate bugs."
Bon, heu, au moins ils sont au courant, et on est au moins 2 à avoir
rapporté le même bug !
Bon, je viens de m'inscrire et de faire mon rapport de bug !
Hourra, je viens d'avoir une réponse d'Apole à mon rapport de bug (en 8 jours, pas mal)... Je cite (même si il y a un avertissement de non- disclosure) :
"After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering. This issue has been filed in our bug database under the original Bug ID# 2968675. The original bug number being used to track this duplicate issue can be found in the State column, in this format: Duplicate/OrigBug#.
Thank you for submitting this bug report. We truly appreciate your assistance in helping us discover and isolate bugs."
Bon, heu, au moins ils sont au courant, et on est au moins 2 à avoir rapporté le même bug !
Paul Gaborit
À (at) Wed, 10 Dec 2008 13:41:55 -0800 (PST), écrivait (wrote):
Hourra, je viens d'avoir une réponse d'Apole à mon rapport de bug (en 8 jours, pas mal)...
Bravo... ;-)
Je cite (même si il y a un avertissement de non- disclosure) :
"After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering. This issue has been filed in our bug database under the original Bug ID# 2968675. The original bug number being used to track this duplicate issue can be found in the State column, in this format: Duplicate/OrigBug#.
Thank you for submitting this bug report. We truly appreciate your assistance in helping us discover and isolate bugs."
Bon, heu, au moins ils sont au courant, et on est au moins 2 à avoir rapporté le même bug !
Je ne suis pas inscrit chez Apple mais j'aimerais savoir une chose : sans violer les règles de confidentialité d'Apple, pourriez-vous nous dire de quand date le signalement du premier bug ? Ça permettrait d'estimer le temps de réaction d'Apple sur ce problème particulier.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 10 Dec 2008 13:41:55 -0800 (PST),
googleg@ifrance.com écrivait (wrote):
Hourra, je viens d'avoir une réponse d'Apole à mon rapport de bug (en
8 jours, pas mal)...
Bravo... ;-)
Je cite (même si il y a un avertissement de non- disclosure) :
"After further investigation it has been determined that this is a
known issue, which is currently being investigated by engineering.
This issue has been filed in our bug database under the original Bug
ID# 2968675. The original bug number being used to track this
duplicate issue can be found in the State column, in this format:
Duplicate/OrigBug#.
Thank you for submitting this bug report. We truly appreciate your
assistance in helping us discover and isolate bugs."
Bon, heu, au moins ils sont au courant, et on est au moins 2 à avoir
rapporté le même bug !
Je ne suis pas inscrit chez Apple mais j'aimerais savoir une chose :
sans violer les règles de confidentialité d'Apple, pourriez-vous nous
dire de quand date le signalement du premier bug ? Ça permettrait
d'estimer le temps de réaction d'Apple sur ce problème particulier.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 10 Dec 2008 13:41:55 -0800 (PST), écrivait (wrote):
Hourra, je viens d'avoir une réponse d'Apole à mon rapport de bug (en 8 jours, pas mal)...
Bravo... ;-)
Je cite (même si il y a un avertissement de non- disclosure) :
"After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering. This issue has been filed in our bug database under the original Bug ID# 2968675. The original bug number being used to track this duplicate issue can be found in the State column, in this format: Duplicate/OrigBug#.
Thank you for submitting this bug report. We truly appreciate your assistance in helping us discover and isolate bugs."
Bon, heu, au moins ils sont au courant, et on est au moins 2 à avoir rapporté le même bug !
Je ne suis pas inscrit chez Apple mais j'aimerais savoir une chose : sans violer les règles de confidentialité d'Apple, pourriez-vous nous dire de quand date le signalement du premier bug ? Ça permettrait d'estimer le temps de réaction d'Apple sur ce problème particulier.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Eric Levenez
Le 11/12/08 10:42, dans , « Paul Gaborit » a écrit :
Ça permettrait d'estimer le temps de réaction d'Apple sur ce problème particulier.
Je pense qu'Apple, corrige certains bugs, uniquement dans la version n+1 d'un logiciel, pour montrer que son système évolue. Je ne serais pas étonné que Mac OS X 10.6 corrige ce problème et que Mac OS X 10.5 n'ait jamais aucun patch. Enfin, ce que je dis...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 11/12/08 10:42, dans <wt9d4fzcakk.fsf@marceau.enstimac.fr>, « Paul
Gaborit » <Paul.Gaborit@invalid.invalid> a écrit :
Ça permettrait
d'estimer le temps de réaction d'Apple sur ce problème particulier.
Je pense qu'Apple, corrige certains bugs, uniquement dans la version n+1
d'un logiciel, pour montrer que son système évolue. Je ne serais pas étonné
que Mac OS X 10.6 corrige ce problème et que Mac OS X 10.5 n'ait jamais
aucun patch. Enfin, ce que je dis...
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 11/12/08 10:42, dans , « Paul Gaborit » a écrit :
Ça permettrait d'estimer le temps de réaction d'Apple sur ce problème particulier.
Je pense qu'Apple, corrige certains bugs, uniquement dans la version n+1 d'un logiciel, pour montrer que son système évolue. Je ne serais pas étonné que Mac OS X 10.6 corrige ce problème et que Mac OS X 10.5 n'ait jamais aucun patch. Enfin, ce que je dis...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
