bizarrerie fichiers

Le 2/12/03 22:00, dans <1g5cqja.gyfj9w15wac8sN@[192.168.0.120]>, « David
Andriana » <david.andriana@free.fr> a écrit :

Éric Lévénez <news@levenez.com> wrote:

en plus, les fichiers Mac peuvent utiliser des méta-données !

Heu ? Quel rapport ?

On peut indiquer en annexe du fichier comment il est encodé. Cela pour
faciliter le travail des diverses couches de conversion.

Et donc si il y des problèmes avec les noms des fichiers c'est à cause des
méta-datas ? J'ai du mal à te suivre.

Pour le
coup, il n'y a pas vraiment de raison technique à ce que ça marche aussi
mal.

HFS+ est une grosse raison.

Pas d'accord : HFS+ est une contrainte qui oblige à faire d'une certaine
façon, pas une raison de mal faire.

Et bien si HFS+ est une contrainte, pourquoi ne pas la faire sauter ?

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Éric Lévénez <news@levenez.com> wrote:

La gestion des liens unix sous HFS+ est une daube, effectivement.

et donc, en supprimant le lien et son roiginal, mon ls predns une
apparence normale ; j'aurais du essayer de remplacer le lien par
l'original pour voir
--
Philippe Manet

Le 2/12/03 23:26, dans <200312022326196496744@[10.0.0.1]>, « manet »
<pmanet@invivo.edu> a écrit :

Éric Lévénez <news@levenez.com> wrote:

La gestion des liens unix sous HFS+ est une daube, effectivement.

et donc, en supprimant le lien et son roiginal, mon ls predns une
apparence normale

Pas normal. C'est le "ls" du système où un truc rajouté ? (sous bash "type
ls" donne /bin/ls ?)

Que le fichier pointe sur quelque chose ou non, cela ne change pas son nom
ou le fait que le lien existe. Si l'on fait "ls -lL" le lien est résolu,
s'il le peut, mais il n'y a pas de message d'erreur s'il ne le peut pas.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Éric Lévénez <news@levenez.com> wrote:

Et donc si il y des problèmes avec les noms des fichiers c'est à cause des
méta-datas ? J'ai du mal à te suivre.

Pas mal, celle-là :-)

Non, je voulais dire que si différents encodages sont utilisés pour les
fichiers, il est possible d'utiliser les méta-données pour indiquer
aussi souvent que nécessaire de quel encodage il s'agit.

Et tu avais parfaitement compris :-)

Et bien si HFS+ est une contrainte, pourquoi ne pas la faire sauter ?

Je te suis à 100% là-dessus.

Par rapport à l'existant (fonctionnalités et embêtements), on aurait au
moins besoin de :
- sensibilité à la casse (c'est aux API de haut niveau de s'adapter,
après tout, pas au système de fichiers d'être miséreux)
- droits
- hard links, symbolic links
- méta-données
- noms longs
- aliasing (est-ce bien de niveau file system ?)

Cela pour concilier les besoins concrets d'Unix (désolé, mais un BSD sur
HFS+, ça ne marche pas) et les facilités de MacOS.


--
David

Le 3/12/03 8:12, dans <1g5dq6a.46r5ui172ulwxN@[192.168.0.120]>, « David
Andriana » <david.andriana@free.fr> a écrit :

Éric Lévénez <news@levenez.com> wrote:

Et donc si il y des problèmes avec les noms des fichiers c'est à cause des
méta-datas ? J'ai du mal à te suivre.

Pas mal, celle-là :-)

Non, je voulais dire que si différents encodages sont utilisés pour les
fichiers, il est possible d'utiliser les méta-données pour indiquer
aussi souvent que nécessaire de quel encodage il s'agit.

Et tu avais parfaitement compris :-)

Non car on parlais de l'encodage du nom du fichier, pas de son contenu. Et
pour le nom, sous UFS c'est de l'octet libre, et sur HFS+ c'est de l'Unicode
16 bits. Et comme on parlais de l'HFS+, le format d'encodage est
parfaitement connu et défini, et les méta-datas n'apportent rien pour
résoudre le problème actuel des noms.

Et bien si HFS+ est une contrainte, pourquoi ne pas la faire sauter ?

Je te suis à 100% là-dessus.

Par rapport à l'existant (fonctionnalités et embêtements), on aurait au
moins besoin de :
- sensibilité à la casse (c'est aux API de haut niveau de s'adapter,
après tout, pas au système de fichiers d'être miséreux)

Il parait qu'il y a une version HFS+ qui gère la casse. Jamais réussi à
formater une partition avec.

- droits

Il sont déjà gérés (sauf sus Mac OS 9 bien sûr).

- hard links, symbolic links

Là effectivement ce ne sont pas des fonctionnalités natives d'HFS+, et les
hacks d'Apple ne sont pas toujours très "stables".

- méta-données

Je ne vois pas l'utilité. C'est une très grosse source d'emmerdements.

- noms longs

Plus de 255 caractères ? Ou alors Unicode 4 ?

- aliasing (est-ce bien de niveau file system ?)

Je ne vois pas de quoi tu parles.

Cela pour concilier les besoins concrets d'Unix (désolé, mais un BSD sur
HFS+, ça ne marche pas) et les facilités de MacOS.

Il y a d'autres fonctionnalités d'un FS, comme la journalisation, les
snapsshots, les tailles des structures dynamiques, une véritable gestion des
volumes par dessus...

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Et bien si HFS+ est une contrainte, pourquoi ne pas la faire sauter ?

Le HFS+ n'est pas qu'une contrainte, c'est juste un système de fichier à
l'origine non conçu pour être compatible avec les système de fichiers
unix. C'est un format qui est beaucoup plus riche que la plupart des
systèmes de fichiers existant. Ce qui est dommage, c'est qu'il n'est pas
toujours utilisé dans le maximum de ses capacités, et qu'il n'y a pas eu
de nouvelle version compatible unix (mais juste une adaptation avec des
hacks).

Je te suis à 100% là-dessus.

Par rapport à l'existant (fonctionnalités et embêtements), on aurait au
moins besoin de :
- sensibilité à la casse (c'est aux API de haut niveau de s'adapter,
après tout, pas au système de fichiers d'être miséreux)

Il parait qu'il y a une version HFS+ qui gère la casse. Jamais réussi à
formater une partition avec.

Quelle idée aussi d'avoir deux fichiers identiques avec juste des
différences de casse. Dans l'absolu, c'est inutile et sans intérêt. Cela
n'empèche cependant pas d'avoir un système qui gère ces différences
(simplement par ce que c'est plus simple, et qui dit plus simple dit
moins de bugs car moins de situations tordues).

- hard links, symbolic links

Là effectivement ce ne sont pas des fonctionnalités natives d'HFS+, et les
hacks d'Apple ne sont pas toujours très "stables".

C'est dommageŠ

- méta-données

Je ne vois pas l'utilité. C'est une très grosse source d'emmerdements.

Ce n'est absolument pas une source d'emmerdements, car ces données ne
sont interprétées que par les applications. Le système ne s'en sert
jamais. C'est tout de même très pratique, par exemple pour donner
l'encodage d'un fichier texte ou pour définir si un fichier est visible
ou non (c'est beaucoup plus propre que le "." en tête de nom)

- noms longs

Plus de 255 caractères ? Ou alors Unicode 4 ?

255 caractères, c'est largement suffisant ! De toute façon un nom de
fichier de plus de 255 caractères est un nom vraiment mal choisit.

- aliasing (est-ce bien de niveau file system ?)

Je ne vois pas de quoi tu parles.

Je pense qu'il parle des alias. Pour le système de fichier, un alias est
un document, c'est les couches du système qui l'interprète comme un
alias.

--
Schmurtz

Éric Lévénez <news@levenez.com> wrote:

Pas normal. C'est le "ls" du système où un truc rajouté ? (sous bash "type
ls" donne /bin/ls ?)

tcsh standard sous 10.2.8
je me suis mal exprimé, j'ai aussi supprimé l'alias !
c'est lui qui était dans mon repertoire home et qui était vu bizarement
par ls
--
Philippe Manet

David Andriana <david.andriana@free.fr> wrote:

Quel est le nom de ce fichier de résultat ?

le problème est que je n'en sais rien, puisque le log de la console me
montre un plantage au moment d'écrire ce fichier...
mais j'ai demandé qu'on m'envoie les sources (j'en parle dans fcsm.prog)
--
Philippe Manet

Le 3/12/03 22:04, dans <bqm80s$1ap$1@news.polytechnique.fr>,
« HitomiMatsushita » <nszgwagkedl-lxlhyne@rzyuh.com> a écrit :

Tu as oublié de quoter les noms des personnes ce qui rend ce thread
illisible car on ne sait plus qui a dit quoi.

Et bien si HFS+ est une contrainte, pourquoi ne pas la faire sauter ?

Le HFS+ n'est pas qu'une contrainte, c'est juste un système de fichier à
l'origine non conçu pour être compatible avec les système de fichiers
unix.

HFS+ est un vieux système de fichier qui n'est pas à la hauteur de Mac OS X,
le fait qu'il soit conçu sans toutes les contraintes Posix n'excuse pas son
utilisation actuelle.

C'est un format qui est beaucoup plus riche que la plupart des
systèmes de fichiers existant.

Crois-tu ? Il existe des fs unix avec des flots type données/ressources, et
ne parlons pas de NTFS qui a aussi cette notion, mais non limitée à 2 flux
comme sur HFS+. Mais le plus important n'est pas ce qu'un fs peut faire,
c'est ce que l'on en fait couramment avec les outils du système. En 10 ans,
pratiquement aucun développeur sous Windows NT n'a fait une appli qui
utilisait les flots. C'est bien sûr l'inverse sur Mac OS 9, mais Mac OS X
est en train d'inverser la tendance.

Ce qui est dommage, c'est qu'il n'est pas
toujours utilisé dans le maximum de ses capacités, et qu'il n'y a pas eu
de nouvelle version compatible unix (mais juste une adaptation avec des
hacks).

Personne sous unix ou Linux ne veut porter HFS+, et pourtant les sources
sont dispos pour darwin.

Quand un Macounet envoie par exemple un fichier Office par email à un
Windosien, 9 fois sur 10 il y a un problème lié aux ressources. Ce problème
remonte régulièrement.

Je te suis à 100% là-dessus.

Par rapport à l'existant (fonctionnalités et embêtements), on aurait au
moins besoin de :
- sensibilité à la casse (c'est aux API de haut niveau de s'adapter,
après tout, pas au système de fichiers d'être miséreux)

Il parait qu'il y a une version HFS+ qui gère la casse. Jamais réussi à
formater une partition avec.

Quelle idée aussi d'avoir deux fichiers identiques avec juste des
différences de casse.

L'idée est de relire des archives unix normales. Impossible de faire cela
sans perte de certains fichiers. Alors on peut, comme tu le fais, dire qu'il
faut que tout le monde arrête de gérer la casse, mais pour moi, je préfère
avoir le choix. Je n'aime pas perdre des données.

Dans l'absolu, c'est inutile et sans intérêt.

Dans l'absolu c'est utile et vital dans certains cas. Apple, lui, l'a
compris en essayant d'introduire en douceur la gestion de la casse dans
HFS+. Si HFS+ doit être utilisé dans des serveurs de fichiers pour des
machines unix ou linux, c'est obligatoire.

Cela
n'empèche cependant pas d'avoir un système qui gère ces différences
(simplement par ce que c'est plus simple, et qui dit plus simple dit
moins de bugs car moins de situations tordues).

Le problème sous Mac OS X c'est que le système gère la casse (plus ou moins
bien) à travers UFS et le nouvel HFS+, mais hélas de nombreuses applications
ne le font pas. C'est souvent la faute du programmeur (même pour certaines
application Apple).

- hard links, symbolic links

Là effectivement ce ne sont pas des fonctionnalités natives d'HFS+, et les
hacks d'Apple ne sont pas toujours très "stables".

C'est dommageŠ

C'est HFS+

- méta-données

Je ne vois pas l'utilité. C'est une très grosse source d'emmerdements.

Ce n'est absolument pas une source d'emmerdements, car ces données ne
sont interprétées que par les applications. Le système ne s'en sert
jamais. C'est tout de même très pratique, par exemple pour donner
l'encodage d'un fichier texte ou pour définir si un fichier est visible
ou non (c'est beaucoup plus propre que le "." en tête de nom)

Dit cela à ceux qui ne peuvent vider la poubelle à cause d'un drapeau HFS+
bien planqué.

- noms longs

Plus de 255 caractères ? Ou alors Unicode 4 ?

255 caractères, c'est largement suffisant ! De toute façon un nom de
fichier de plus de 255 caractères est un nom vraiment mal choisit.

Et le fait qu'HFS+ ne gère pas tous les caractères Unicode de Panther ?

- aliasing (est-ce bien de niveau file system ?)

Je ne vois pas de quoi tu parles.

Je pense qu'il parle des alias. Pour le système de fichier, un alias est
un document, c'est les couches du système qui l'interprète comme un
alias.

Et non, ce n'est pas le système qui interprète les alias, c'est chaque
application ! C'est la pire chose de Mac OS X ! Si encore le système gérait
en interne les alias, mais non ! Et cela entraîne problème sur problème.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Le 3/12/03 23:30, dans <2003120323301911707879@[10.0.0.1]>, « manet »
<pmanet@invivo.edu> a écrit :

Éric Lévénez <news@levenez.com> wrote:

Pas normal. C'est le "ls" du système où un truc rajouté ? (sous bash "type
ls" donne /bin/ls ?)

tcsh standard sous 10.2.8

Mais je ne parle pas du shell, je parle de la commande ls ! Et je ne parle
pas non plus d'une fonction shell ls ou d'un alias shell ls.

je me suis mal exprimé, j'ai aussi supprimé l'alias !

Ce n'était pas un alias mais un lien, ou alors il y a quelque chose que tu
n'as pas dit.

c'est lui qui était dans mon repertoire home et qui était vu bizarement
par ls

Bon, je confirme que je ne comprends absolument plus rien à ton problème. Je
ne sais plus si le fichier était un lien ou un alias, ni quelle commande tu
faisais pour l'afficher le fichier (mélange du shell et de ls), ni...

Bref j'arrête d'essayer de comprendre :-/

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.