Dans l'article <C11D1AB9.7922F%, Eric Levenez écrit:
En HFS par exemple un fichier peut faire 255 caractères (pas octet) de long. La limite du PATH est généralement celle de X/Open, soit 1024 octets. En NFS c'est aussi 1024 octets. Sous X11, c'est 4096 octets. En Posix c'est 256 octets.
Je suppose que le 256 est une limite minimale (i.e. un système POSIX est obligé d'accepter des noms de cette taille, mais peut accepter plus). Concernant le C (ISO C99):
[Draft WG14/N869]
FILENAME_MAX
which expands to an integer constant expression that is the size needed for an array of char large enough to hold the longest file name string that the implementation guarantees can be opened;208)
208If the implementation imposes no practical limit on the length of file name strings, the value of FILENAME_MAX should instead be the recommended size of an array intended to hold a file name string. Of course, file name string contents are subject to other system-specific constraints; therefore all possible strings of length FILENAME_MAX cannot be expected to be opened successfully.
Dans l'article <C11D1AB9.7922F%news@levenez.com>,
Eric Levenez <news@levenez.com> écrit:
En HFS par exemple un fichier peut faire 255 caractères (pas octet)
de long. La limite du PATH est généralement celle de X/Open, soit
1024 octets. En NFS c'est aussi 1024 octets. Sous X11, c'est 4096
octets. En Posix c'est 256 octets.
Je suppose que le 256 est une limite minimale (i.e. un système POSIX
est obligé d'accepter des noms de cette taille, mais peut accepter
plus). Concernant le C (ISO C99):
[Draft WG14/N869]
FILENAME_MAX
which expands to an integer constant expression that is the
size needed for an array of char large enough to hold the
longest file name string that the implementation guarantees
can be opened;208)
208If the implementation imposes no practical limit on the
length of file name strings, the value of FILENAME_MAX
should instead be the recommended size of an array
intended to hold a file name string. Of course, file
name string contents are subject to other system-specific
constraints; therefore all possible strings of length
FILENAME_MAX cannot be expected to be opened
successfully.
Dans l'article <C11D1AB9.7922F%, Eric Levenez écrit:
En HFS par exemple un fichier peut faire 255 caractères (pas octet) de long. La limite du PATH est généralement celle de X/Open, soit 1024 octets. En NFS c'est aussi 1024 octets. Sous X11, c'est 4096 octets. En Posix c'est 256 octets.
Je suppose que le 256 est une limite minimale (i.e. un système POSIX est obligé d'accepter des noms de cette taille, mais peut accepter plus). Concernant le C (ISO C99):
[Draft WG14/N869]
FILENAME_MAX
which expands to an integer constant expression that is the size needed for an array of char large enough to hold the longest file name string that the implementation guarantees can be opened;208)
208If the implementation imposes no practical limit on the length of file name strings, the value of FILENAME_MAX should instead be the recommended size of an array intended to hold a file name string. Of course, file name string contents are subject to other system-specific constraints; therefore all possible strings of length FILENAME_MAX cannot be expected to be opened successfully.
si, mais je n'avais pas donné l'info idoine, car dans certains cas (l'utilisateur a entré non pas le path d'un fichier mais le path vers l'alias d'un fichier) je dois résoudre l'alias et là le path est différent...
OK. Dans ce cas oui.
Pour résoudre l'alias, c'est une ouverture de fichier ? Si oui, tu dois pouvoir déterminer la taille de ce fichier...
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Une bévue <pere.noel@laponie.com.invalid> wrote:
si, mais je n'avais pas donné l'info idoine, car dans certains cas
(l'utilisateur a entré non pas le path d'un fichier mais le path vers
l'alias d'un fichier) je dois résoudre l'alias et là le path est
différent...
OK. Dans ce cas oui.
Pour résoudre l'alias, c'est une ouverture de fichier ?
Si oui, tu dois pouvoir déterminer la taille de ce fichier...
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
si, mais je n'avais pas donné l'info idoine, car dans certains cas (l'utilisateur a entré non pas le path d'un fichier mais le path vers l'alias d'un fichier) je dois résoudre l'alias et là le path est différent...
OK. Dans ce cas oui.
Pour résoudre l'alias, c'est une ouverture de fichier ? Si oui, tu dois pouvoir déterminer la taille de ce fichier...
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
blanc
FiLH wrote:
Maintenant... tu viens de découvrir la cause numéro 1 des bugs, tour de sécurités, défauts de portabilité, plantages : l'allocation statique.
Ou pire l'allocation dynamique dont on a pas testé le résultat. On se dit ça passera, ou bien on mettra le test plus tard et puis on oublie ;-(
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
FiLH <filh@filh.orgie> wrote:
Maintenant... tu viens de découvrir la cause numéro 1 des bugs, tour de
sécurités, défauts de portabilité, plantages : l'allocation statique.
Ou pire l'allocation dynamique dont on a pas testé le résultat. On se
dit ça passera, ou bien on mettra le test plus tard et puis on oublie
;-(
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
Maintenant... tu viens de découvrir la cause numéro 1 des bugs, tour de sécurités, défauts de portabilité, plantages : l'allocation statique.
Ou pire l'allocation dynamique dont on a pas testé le résultat. On se dit ça passera, ou bien on mettra le test plus tard et puis on oublie ;-(
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
FiLH
(JPaul) writes:
FiLH wrote:
Maintenant... tu viens de découvrir la cause numéro 1 des bugs, tour de sécurités, défauts de portabilité, plantages : l'allocation statique.
Ou pire l'allocation dynamique dont on a pas testé le résultat. On se dit ça passera, ou bien on mettra le test plus tard et puis on oublie ;-(
gnarf gnarf... mais bon c'est un truc un peu rare de nos jours où les gigas se multiplient.
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 (JPaul) writes:
FiLH <filh@filh.orgie> wrote:
Maintenant... tu viens de découvrir la cause numéro 1 des bugs, tour de
sécurités, défauts de portabilité, plantages : l'allocation statique.
Ou pire l'allocation dynamique dont on a pas testé le résultat. On se
dit ça passera, ou bien on mettra le test plus tard et puis on oublie
;-(
gnarf gnarf... mais bon c'est un truc un peu rare de nos jours où les
gigas se multiplient.
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/
Maintenant... tu viens de découvrir la cause numéro 1 des bugs, tour de sécurités, défauts de portabilité, plantages : l'allocation statique.
Ou pire l'allocation dynamique dont on a pas testé le résultat. On se dit ça passera, ou bien on mettra le test plus tard et puis on oublie ;-(
gnarf gnarf... mais bon c'est un truc un peu rare de nos jours où les gigas se multiplient.
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
FiLH wrote:
gnarf gnarf... mais bon c'est un truc un peu rare de nos jours où les gigas se multiplient.
Détrompe-toi. Les gigas se multiplient mais on en profite pour lancer plein d'applis en même temps ce qui occupe vite la place mémoire. Même la mémoire virtuelle peut arriver à saturation parce qu'on aura trop rempli le ou les disques où sont stockés les swapfiles.
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
FiLH <filh@filh.org> wrote:
gnarf gnarf... mais bon c'est un truc un peu rare de nos jours où les
gigas se multiplient.
Détrompe-toi. Les gigas se multiplient mais on en profite pour lancer
plein d'applis en même temps ce qui occupe vite la place mémoire. Même
la mémoire virtuelle peut arriver à saturation parce qu'on aura trop
rempli le ou les disques où sont stockés les swapfiles.
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
gnarf gnarf... mais bon c'est un truc un peu rare de nos jours où les gigas se multiplient.
Détrompe-toi. Les gigas se multiplient mais on en profite pour lancer plein d'applis en même temps ce qui occupe vite la place mémoire. Même la mémoire virtuelle peut arriver à saturation parce qu'on aura trop rempli le ou les disques où sont stockés les swapfiles.
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
FiLH
(JPaul) writes:
FiLH wrote:
gnarf gnarf... mais bon c'est un truc un peu rare de nos jours où les gigas se multiplient.
Détrompe-toi. Les gigas se multiplient mais on en profite pour lancer plein d'applis en même temps ce qui occupe vite la place mémoire. Même la mémoire virtuelle peut arriver à saturation parce qu'on aura trop rempli le ou les disques où sont stockés les swapfiles.
Oui remarque j'oubliais que sur le Mac les swapfiles ne décroissent jamais..
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 (JPaul) writes:
FiLH <filh@filh.org> wrote:
gnarf gnarf... mais bon c'est un truc un peu rare de nos jours où les
gigas se multiplient.
Détrompe-toi. Les gigas se multiplient mais on en profite pour lancer
plein d'applis en même temps ce qui occupe vite la place mémoire. Même
la mémoire virtuelle peut arriver à saturation parce qu'on aura trop
rempli le ou les disques où sont stockés les swapfiles.
Oui remarque j'oubliais que sur le Mac les swapfiles ne décroissent
jamais..
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/
gnarf gnarf... mais bon c'est un truc un peu rare de nos jours où les gigas se multiplient.
Détrompe-toi. Les gigas se multiplient mais on en profite pour lancer plein d'applis en même temps ce qui occupe vite la place mémoire. Même la mémoire virtuelle peut arriver à saturation parce qu'on aura trop rempli le ou les disques où sont stockés les swapfiles.
Oui remarque j'oubliais que sur le Mac les swapfiles ne décroissent jamais..
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/
pere.noel
JPaul wrote:
Pour résoudre l'alias, c'est une ouverture de fichier ?
euh non, en fait le programme que j'écris en ce moment est une C extension de Ruby qui permettra de résoudre des alias records en utilisant le File Manager.
la première fois je crée un AliasHandle qui contient les infos nécessaires au File Manager pour s'y retrouver et ensuite, quand le besoin s'en fait sentir, avec cet AliasHandle le File Manager est capable de retrouver le fichier si l'utilisateur en a changé le nom et/ou l'emplacement ou même après un backup recovery.
ceci sans utiliser d'alias file (Finder) "physiques". -- une bévue
JPaul <blanc@empty.org> wrote:
Pour résoudre l'alias, c'est une ouverture de fichier ?
euh non, en fait le programme que j'écris en ce moment est une C
extension de Ruby qui permettra de résoudre des alias records en
utilisant le File Manager.
la première fois je crée un AliasHandle qui contient les infos
nécessaires au File Manager pour s'y retrouver et ensuite, quand le
besoin s'en fait sentir, avec cet AliasHandle le File Manager est
capable de retrouver le fichier si l'utilisateur en a changé le nom
et/ou l'emplacement ou même après un backup recovery.
ceci sans utiliser d'alias file (Finder) "physiques".
--
une bévue
Pour résoudre l'alias, c'est une ouverture de fichier ?
euh non, en fait le programme que j'écris en ce moment est une C extension de Ruby qui permettra de résoudre des alias records en utilisant le File Manager.
la première fois je crée un AliasHandle qui contient les infos nécessaires au File Manager pour s'y retrouver et ensuite, quand le besoin s'en fait sentir, avec cet AliasHandle le File Manager est capable de retrouver le fichier si l'utilisateur en a changé le nom et/ou l'emplacement ou même après un backup recovery.
ceci sans utiliser d'alias file (Finder) "physiques". -- une bévue
root
Le Fri, 01 Sep 2006 00:43:10 +0200, Une bévue a écrit :
c'est curieux cette limite du path, courte amha, car 256 caractères (en UTF16) ça peut déjà donner, pour le seul nom du fichier 1022 octets...
C'est pas grave de ne pas connaitre la longueur max du nom/chemin d'accès d'un fichier si tu ne déclares jamais tes chaines en statique et que tu vérifies bien les codes retour des fonctions. Si tu depasse une limite du système, il y aura toujours un appel système qui te retournera -1 ou un errno pour t'indiquer que tu as fait quelque chose qu'il n'aime pas ;)
Le Fri, 01 Sep 2006 00:43:10 +0200, Une bévue a écrit :
c'est curieux cette limite du path, courte amha, car 256 caractères (en
UTF16) ça peut déjà donner, pour le seul nom du fichier 1022 octets...
C'est pas grave de ne pas connaitre la longueur max du nom/chemin
d'accès d'un fichier si tu ne déclares jamais tes chaines en statique et
que tu vérifies bien les codes retour des fonctions.
Si tu depasse une limite du système, il y aura toujours un appel système
qui te retournera -1 ou un errno pour t'indiquer que tu as fait quelque
chose qu'il n'aime pas ;)
Le Fri, 01 Sep 2006 00:43:10 +0200, Une bévue a écrit :
c'est curieux cette limite du path, courte amha, car 256 caractères (en UTF16) ça peut déjà donner, pour le seul nom du fichier 1022 octets...
C'est pas grave de ne pas connaitre la longueur max du nom/chemin d'accès d'un fichier si tu ne déclares jamais tes chaines en statique et que tu vérifies bien les codes retour des fonctions. Si tu depasse une limite du système, il y aura toujours un appel système qui te retournera -1 ou un errno pour t'indiquer que tu as fait quelque chose qu'il n'aime pas ;)
pere.noel
root wrote:
C'est pas grave de ne pas connaitre la longueur max du nom/chemin d'accès d'un fichier si tu ne déclares jamais tes chaines en statique et que tu vérifies bien les codes retour des fonctions. Si tu depasse une limite du système, il y aura toujours un appel système qui te retournera -1 ou un errno pour t'indiquer que tu as fait quelque chose qu'il n'aime pas ;)
OK, merci. -- une bévue
root <root@localhost.localdomain> wrote:
C'est pas grave de ne pas connaitre la longueur max du nom/chemin
d'accès d'un fichier si tu ne déclares jamais tes chaines en statique et
que tu vérifies bien les codes retour des fonctions.
Si tu depasse une limite du système, il y aura toujours un appel système
qui te retournera -1 ou un errno pour t'indiquer que tu as fait quelque
chose qu'il n'aime pas ;)
C'est pas grave de ne pas connaitre la longueur max du nom/chemin d'accès d'un fichier si tu ne déclares jamais tes chaines en statique et que tu vérifies bien les codes retour des fonctions. Si tu depasse une limite du système, il y aura toujours un appel système qui te retournera -1 ou un errno pour t'indiquer que tu as fait quelque chose qu'il n'aime pas ;)
