le pb vient de se reproduire :
lydie% ls -l
ls: lentilles-vertes.jpg: Invalid argument
ls: lentillons-de-champagne.jpg: Invalid argument
lydie% ls -lw
ls: lentilles-vertes.jpg: Invalid argument
ls: lentillons-de-champagne.jpg: Invalid argument
Si je peux me mêler de ce fil,
l'erreur n'est pas "fichier
inexistant"
(no such file or directory) mais "argument invalide", ce
qui n'est pas tout à fait pareil et qui aurait tendance à prouver que
les noms de fichier sont interprêtés comme "arguments" alors qu'ils
n'ont pas été tapés...
Trois pistes me viennent à l'esprit :
- caractères "bizarres" mais non-imprimables dans les noms de fichier
(mais je n'y crois pas trop) : essayer ls -lB
- alias de la commande "ls" positionné dans le shell, taper : alias
pour savoir
- noms de fichier commançant par -
Que donne : ls lentill<TAB>
ou ls <TAB>TAB>,
<TAB> réprésqentant la
tabulation, ce qui demande au shell de faire l'expansion des noms de
fichier qui commencent par "lentill" ?
le pb vient de se reproduire :
lydie% ls -l
ls: lentilles-vertes.jpg: Invalid argument
ls: lentillons-de-champagne.jpg: Invalid argument
lydie% ls -lw
ls: lentilles-vertes.jpg: Invalid argument
ls: lentillons-de-champagne.jpg: Invalid argument
Si je peux me mêler de ce fil,
l'erreur n'est pas "fichier
inexistant"
(no such file or directory) mais "argument invalide", ce
qui n'est pas tout à fait pareil et qui aurait tendance à prouver que
les noms de fichier sont interprêtés comme "arguments" alors qu'ils
n'ont pas été tapés...
Trois pistes me viennent à l'esprit :
- caractères "bizarres" mais non-imprimables dans les noms de fichier
(mais je n'y crois pas trop) : essayer ls -lB
- alias de la commande "ls" positionné dans le shell, taper : alias
pour savoir
- noms de fichier commançant par -
Que donne : ls lentill<TAB>
ou ls <TAB>TAB>,
<TAB> réprésqentant la
tabulation, ce qui demande au shell de faire l'expansion des noms de
fichier qui commencent par "lentill" ?
le pb vient de se reproduire :
lydie% ls -l
ls: lentilles-vertes.jpg: Invalid argument
ls: lentillons-de-champagne.jpg: Invalid argument
lydie% ls -lw
ls: lentilles-vertes.jpg: Invalid argument
ls: lentillons-de-champagne.jpg: Invalid argument
Si je peux me mêler de ce fil,
l'erreur n'est pas "fichier
inexistant"
(no such file or directory) mais "argument invalide", ce
qui n'est pas tout à fait pareil et qui aurait tendance à prouver que
les noms de fichier sont interprêtés comme "arguments" alors qu'ils
n'ont pas été tapés...
Trois pistes me viennent à l'esprit :
- caractères "bizarres" mais non-imprimables dans les noms de fichier
(mais je n'y crois pas trop) : essayer ls -lB
- alias de la commande "ls" positionné dans le shell, taper : alias
pour savoir
- noms de fichier commançant par -
Que donne : ls lentill<TAB>
ou ls <TAB>TAB>,
<TAB> réprésqentant la
tabulation, ce qui demande au shell de faire l'expansion des noms de
fichier qui commencent par "lentill" ?
Le 15/05/07 14:45, dans
,
« Thomas » a écrit :le pb vient de se reproduire :
lydie% ls -l
ls: lentilles-vertes.jpg: Invalid argument
ls: lentillons-de-champagne.jpg: Invalid argument
lydie% ls -lw
ls: lentilles-vertes.jpg: Invalid argument
ls: lentillons-de-champagne.jpg: Invalid argument
La commande "ls" utilise une API bas niveau pour récupérer les noms des
fichiers (normaux ou spéciaux) d'un répertoire. Cette partie, je pense
marche dans ton cas (le simple "ls" doit afficher les 2 noms).
Avec l'option
-l, le programme "ls" cherche à récupérer des informations sur le fichier
(type, taille, date...) et c'est là qu'apparaît le "Invalid argument".
Ce type de code d'erreur ne devrait pas apparaître. C'est le système de
fichier qui le remonte.
Es-tu en HFS+ ?
Le répertoire est-il monté à distance ?
Peut-être que les fichiers sont des liens symboliques
qui se cassent et se
refont. Normalement quand un tel lien est cassé on n'a pas ce code d'erreur,
mais pourtant cela y ressemble.http://biocer.fr/produits/consommateur/legumineuses/lentilles/images/
Cette page est étrange.
Cet après-midi la colonne Size étaient vide : le serveur Apache avait donc
les noms des 2 fichiers mais pas les infos sur ces fichiers. Comme "ls -l"
quoi. Mais ce soir, la colonne "Size" est renseignée avec des tailles. Là je
pense que "ls -l" doit marcher.
L'interface apache et la couche unix sont donc en concordance.
Le problème, que je ne comprends pas, est autre, mais doit être lié au type
de système de fichiers et aux types des 2 fichiers.
Une autre piste est le vérolage du système de fichiers, et là il faudrait
lancer un fsck ou équivalent.
Le 15/05/07 14:45, dans
<fantome.forums.tDeContes-CC5F3F.14453715052007@news-2.proxad.net>,
« Thomas » <fantome.forums.tDeContes@free.fr.invalid> a écrit :
le pb vient de se reproduire :
lydie% ls -l
ls: lentilles-vertes.jpg: Invalid argument
ls: lentillons-de-champagne.jpg: Invalid argument
lydie% ls -lw
ls: lentilles-vertes.jpg: Invalid argument
ls: lentillons-de-champagne.jpg: Invalid argument
La commande "ls" utilise une API bas niveau pour récupérer les noms des
fichiers (normaux ou spéciaux) d'un répertoire. Cette partie, je pense
marche dans ton cas (le simple "ls" doit afficher les 2 noms).
Avec l'option
-l, le programme "ls" cherche à récupérer des informations sur le fichier
(type, taille, date...) et c'est là qu'apparaît le "Invalid argument".
Ce type de code d'erreur ne devrait pas apparaître. C'est le système de
fichier qui le remonte.
Es-tu en HFS+ ?
Le répertoire est-il monté à distance ?
Peut-être que les fichiers sont des liens symboliques
qui se cassent et se
refont. Normalement quand un tel lien est cassé on n'a pas ce code d'erreur,
mais pourtant cela y ressemble.
http://biocer.fr/produits/consommateur/legumineuses/lentilles/images/
Cette page est étrange.
Cet après-midi la colonne Size étaient vide : le serveur Apache avait donc
les noms des 2 fichiers mais pas les infos sur ces fichiers. Comme "ls -l"
quoi. Mais ce soir, la colonne "Size" est renseignée avec des tailles. Là je
pense que "ls -l" doit marcher.
L'interface apache et la couche unix sont donc en concordance.
Le problème, que je ne comprends pas, est autre, mais doit être lié au type
de système de fichiers et aux types des 2 fichiers.
Une autre piste est le vérolage du système de fichiers, et là il faudrait
lancer un fsck ou équivalent.
Le 15/05/07 14:45, dans
,
« Thomas » a écrit :le pb vient de se reproduire :
lydie% ls -l
ls: lentilles-vertes.jpg: Invalid argument
ls: lentillons-de-champagne.jpg: Invalid argument
lydie% ls -lw
ls: lentilles-vertes.jpg: Invalid argument
ls: lentillons-de-champagne.jpg: Invalid argument
La commande "ls" utilise une API bas niveau pour récupérer les noms des
fichiers (normaux ou spéciaux) d'un répertoire. Cette partie, je pense
marche dans ton cas (le simple "ls" doit afficher les 2 noms).
Avec l'option
-l, le programme "ls" cherche à récupérer des informations sur le fichier
(type, taille, date...) et c'est là qu'apparaît le "Invalid argument".
Ce type de code d'erreur ne devrait pas apparaître. C'est le système de
fichier qui le remonte.
Es-tu en HFS+ ?
Le répertoire est-il monté à distance ?
Peut-être que les fichiers sont des liens symboliques
qui se cassent et se
refont. Normalement quand un tel lien est cassé on n'a pas ce code d'erreur,
mais pourtant cela y ressemble.http://biocer.fr/produits/consommateur/legumineuses/lentilles/images/
Cette page est étrange.
Cet après-midi la colonne Size étaient vide : le serveur Apache avait donc
les noms des 2 fichiers mais pas les infos sur ces fichiers. Comme "ls -l"
quoi. Mais ce soir, la colonne "Size" est renseignée avec des tailles. Là je
pense que "ls -l" doit marcher.
L'interface apache et la couche unix sont donc en concordance.
Le problème, que je ne comprends pas, est autre, mais doit être lié au type
de système de fichiers et aux types des 2 fichiers.
Une autre piste est le vérolage du système de fichiers, et là il faudrait
lancer un fsck ou équivalent.
In article (Dans l'article) <C26FC3B0.A7ED5%,
Eric Levenez wrote (écrivait) :Ce type de code d'erreur ne devrait pas apparaître. C'est le système de
fichier qui le remonte.
??
Une autre piste est le vérolage du système de fichiers, et là il faudrait
lancer un fsck ou équivalent.
bonne idée :-)
je vais verifier ca des que possible !
In article (Dans l'article) <C26FC3B0.A7ED5%news@levenez.com>,
Eric Levenez <news@levenez.com> wrote (écrivait) :
Ce type de code d'erreur ne devrait pas apparaître. C'est le système de
fichier qui le remonte.
??
Une autre piste est le vérolage du système de fichiers, et là il faudrait
lancer un fsck ou équivalent.
bonne idée :-)
je vais verifier ca des que possible !
In article (Dans l'article) <C26FC3B0.A7ED5%,
Eric Levenez wrote (écrivait) :Ce type de code d'erreur ne devrait pas apparaître. C'est le système de
fichier qui le remonte.
??
Une autre piste est le vérolage du système de fichiers, et là il faudrait
lancer un fsck ou équivalent.
bonne idée :-)
je vais verifier ca des que possible !
In article (Dans l'article) <C26FC3B0.A7ED5%,
Eric Levenez wrote (écrivait) :L'interface apache et la couche unix sont donc en concordance.
ca me parait logique :
apache utilise directement la couche unix,
alors que le finder utilise peut etre d'autres choses (made in apple)
In article (Dans l'article) <C26FC3B0.A7ED5%news@levenez.com>,
Eric Levenez <news@levenez.com> wrote (écrivait) :
L'interface apache et la couche unix sont donc en concordance.
ca me parait logique :
apache utilise directement la couche unix,
alors que le finder utilise peut etre d'autres choses (made in apple)
In article (Dans l'article) <C26FC3B0.A7ED5%,
Eric Levenez wrote (écrivait) :L'interface apache et la couche unix sont donc en concordance.
ca me parait logique :
apache utilise directement la couche unix,
alors que le finder utilise peut etre d'autres choses (made in apple)
Au final l'interface Posix
directe et Carbon à travers volfs vont accéder aux mêmes infos d'un fichier.
Il doit donc y avoir concordance.
Au final l'interface Posix
directe et Carbon à travers volfs vont accéder aux mêmes infos d'un fichier.
Il doit donc y avoir concordance.
Au final l'interface Posix
directe et Carbon à travers volfs vont accéder aux mêmes infos d'un fichier.
Il doit donc y avoir concordance.
Le Finder est une application unix comme les autres, mais hélas c'est une
application Carbon. Cette API n'est pas Posix et utilise pour référencer un
fichier un numéro unique. Pour rendre cela unix, Apple a créé un système de
fichiers appelé volfs et monté sur "/.vol". La couche applicative Carbon va
accéder, par les API unix, à travers volfs, aux fichiers HFS+. En gros cette
interface volfs n'est qu'une couche en plus. Au final l'interface Posix
directe et Carbon à travers volfs vont accéder aux mêmes infos d'un fichier.
Il doit donc y avoir concordance.
Le Finder est une application unix comme les autres, mais hélas c'est une
application Carbon. Cette API n'est pas Posix et utilise pour référencer un
fichier un numéro unique. Pour rendre cela unix, Apple a créé un système de
fichiers appelé volfs et monté sur "/.vol". La couche applicative Carbon va
accéder, par les API unix, à travers volfs, aux fichiers HFS+. En gros cette
interface volfs n'est qu'une couche en plus. Au final l'interface Posix
directe et Carbon à travers volfs vont accéder aux mêmes infos d'un fichier.
Il doit donc y avoir concordance.
Le Finder est une application unix comme les autres, mais hélas c'est une
application Carbon. Cette API n'est pas Posix et utilise pour référencer un
fichier un numéro unique. Pour rendre cela unix, Apple a créé un système de
fichiers appelé volfs et monté sur "/.vol". La couche applicative Carbon va
accéder, par les API unix, à travers volfs, aux fichiers HFS+. En gros cette
interface volfs n'est qu'une couche en plus. Au final l'interface Posix
directe et Carbon à travers volfs vont accéder aux mêmes infos d'un fichier.
Il doit donc y avoir concordance.
Well, étant donné un fichier dans ./volfs/xxx/toto, comment le retrouver
dans l'arborescence ?
Well, étant donné un fichier dans ./volfs/xxx/toto, comment le retrouver
dans l'arborescence ?
Well, étant donné un fichier dans ./volfs/xxx/toto, comment le retrouver
dans l'arborescence ?
Le 17/05/07 10:33, dans <1hy96ak.tqo24jit6fgrN%, « FiLH »Well, étant donné un fichier dans ./volfs/xxx/toto, comment le retrouver
dans l'arborescence ?
Je vais prendre un exemple :
Avec fs_usage, je vois que le Finder au lancement d'un programme utilise le
fichier "/.vol/234881032/17183338//Contents/PkgInfo". Le "17183338" est le
numéro de l'inode sur la partition "234881032". Comme je n'ai qu'une
Le 17/05/07 10:33, dans <1hy96ak.tqo24jit6fgrN%filh@filh.orgie>, « FiLH »
Well, étant donné un fichier dans ./volfs/xxx/toto, comment le retrouver
dans l'arborescence ?
Je vais prendre un exemple :
Avec fs_usage, je vois que le Finder au lancement d'un programme utilise le
fichier "/.vol/234881032/17183338//Contents/PkgInfo". Le "17183338" est le
numéro de l'inode sur la partition "234881032". Comme je n'ai qu'une
Le 17/05/07 10:33, dans <1hy96ak.tqo24jit6fgrN%, « FiLH »Well, étant donné un fichier dans ./volfs/xxx/toto, comment le retrouver
dans l'arborescence ?
Je vais prendre un exemple :
Avec fs_usage, je vois que le Finder au lancement d'un programme utilise le
fichier "/.vol/234881032/17183338//Contents/PkgInfo". Le "17183338" est le
numéro de l'inode sur la partition "234881032". Comme je n'ai qu'une
Le 16/05/07 16:15, dans
,
« Thomas » a écrit :In article (Dans l'article) <C26FC3B0.A7ED5%,
Eric Levenez wrote (écrivait) :L'interface apache et la couche unix sont donc en concordance.
ca me parait logique :
apache utilise directement la couche unix,
alors que le finder utilise peut etre d'autres choses (made in apple)
Le Finder est une application unix comme les autres, mais hélas c'est une
application Carbon. Cette API n'est pas Posix et utilise pour référencer un
fichier un numéro unique. Pour rendre cela unix, Apple a créé un système de
fichiers appelé volfs et monté sur "/.vol". La couche applicative Carbon va
accéder, par les API unix, à travers volfs, aux fichiers HFS+. En gros cette
interface volfs n'est qu'une couche en plus. Au final l'interface Posix
directe et Carbon à travers volfs vont accéder aux mêmes infos d'un fichier.
Il doit donc y avoir concordance.
Le 16/05/07 16:15, dans
<fantome.forums.tDeContes-1CB29E.16154316052007@news-4.proxad.net>,
« Thomas » <fantome.forums.tDeContes@free.fr.invalid> a écrit :
In article (Dans l'article) <C26FC3B0.A7ED5%news@levenez.com>,
Eric Levenez <news@levenez.com> wrote (écrivait) :
L'interface apache et la couche unix sont donc en concordance.
ca me parait logique :
apache utilise directement la couche unix,
alors que le finder utilise peut etre d'autres choses (made in apple)
Le Finder est une application unix comme les autres, mais hélas c'est une
application Carbon. Cette API n'est pas Posix et utilise pour référencer un
fichier un numéro unique. Pour rendre cela unix, Apple a créé un système de
fichiers appelé volfs et monté sur "/.vol". La couche applicative Carbon va
accéder, par les API unix, à travers volfs, aux fichiers HFS+. En gros cette
interface volfs n'est qu'une couche en plus. Au final l'interface Posix
directe et Carbon à travers volfs vont accéder aux mêmes infos d'un fichier.
Il doit donc y avoir concordance.
Le 16/05/07 16:15, dans
,
« Thomas » a écrit :In article (Dans l'article) <C26FC3B0.A7ED5%,
Eric Levenez wrote (écrivait) :L'interface apache et la couche unix sont donc en concordance.
ca me parait logique :
apache utilise directement la couche unix,
alors que le finder utilise peut etre d'autres choses (made in apple)
Le Finder est une application unix comme les autres, mais hélas c'est une
application Carbon. Cette API n'est pas Posix et utilise pour référencer un
fichier un numéro unique. Pour rendre cela unix, Apple a créé un système de
fichiers appelé volfs et monté sur "/.vol". La couche applicative Carbon va
accéder, par les API unix, à travers volfs, aux fichiers HFS+. En gros cette
interface volfs n'est qu'une couche en plus. Au final l'interface Posix
directe et Carbon à travers volfs vont accéder aux mêmes infos d'un fichier.
Il doit donc y avoir concordance.
Le 16/05/07 16:15, dans
,
« Thomas » a écrit :In article (Dans l'article) <C26FC3B0.A7ED5%,
Eric Levenez wrote (écrivait) :Ce type de code d'erreur ne devrait pas apparaître. C'est le système de
fichier qui le remonte.
??
La commande "ls" utilise l'appel système "stat" pour connaître les
caractéristique d'un fichier. Ce que je voulais dire c'est que ce n'est pas
"ls" qui crée ce code d'erreur (ce n'est pas une erreur applicative) mais
que c'est le système de fichier (HFS+ dans ton cas) qui le retourne, et "ls"
ne fait que transmettre.
Une autre piste est le vérolage du système de fichiers, et là il faudrait
lancer un fsck ou équivalent.
bonne idée :-)
je vais verifier ca des que possible !
Sur un système de fichier type HFS+, les informations liées à un fichier
sont enregistrées dans des structures très compliquées et donc facilement
vérolable.
Je ne suis pas sûr qu'en 10.2 tu aies la journalisation activée
(normalement cela évite les corruptions trop faciles sur HFS+).
Le 16/05/07 16:15, dans
<fantome.forums.tDeContes-1CB29E.16154316052007@news-4.proxad.net>,
« Thomas » <fantome.forums.tDeContes@free.fr.invalid> a écrit :
In article (Dans l'article) <C26FC3B0.A7ED5%news@levenez.com>,
Eric Levenez <news@levenez.com> wrote (écrivait) :
Ce type de code d'erreur ne devrait pas apparaître. C'est le système de
fichier qui le remonte.
??
La commande "ls" utilise l'appel système "stat" pour connaître les
caractéristique d'un fichier. Ce que je voulais dire c'est que ce n'est pas
"ls" qui crée ce code d'erreur (ce n'est pas une erreur applicative) mais
que c'est le système de fichier (HFS+ dans ton cas) qui le retourne, et "ls"
ne fait que transmettre.
Une autre piste est le vérolage du système de fichiers, et là il faudrait
lancer un fsck ou équivalent.
bonne idée :-)
je vais verifier ca des que possible !
Sur un système de fichier type HFS+, les informations liées à un fichier
sont enregistrées dans des structures très compliquées et donc facilement
vérolable.
Je ne suis pas sûr qu'en 10.2 tu aies la journalisation activée
(normalement cela évite les corruptions trop faciles sur HFS+).
Le 16/05/07 16:15, dans
,
« Thomas » a écrit :In article (Dans l'article) <C26FC3B0.A7ED5%,
Eric Levenez wrote (écrivait) :Ce type de code d'erreur ne devrait pas apparaître. C'est le système de
fichier qui le remonte.
??
La commande "ls" utilise l'appel système "stat" pour connaître les
caractéristique d'un fichier. Ce que je voulais dire c'est que ce n'est pas
"ls" qui crée ce code d'erreur (ce n'est pas une erreur applicative) mais
que c'est le système de fichier (HFS+ dans ton cas) qui le retourne, et "ls"
ne fait que transmettre.
Une autre piste est le vérolage du système de fichiers, et là il faudrait
lancer un fsck ou équivalent.
bonne idée :-)
je vais verifier ca des que possible !
Sur un système de fichier type HFS+, les informations liées à un fichier
sont enregistrées dans des structures très compliquées et donc facilement
vérolable.
Je ne suis pas sûr qu'en 10.2 tu aies la journalisation activée
(normalement cela évite les corruptions trop faciles sur HFS+).
