Le Fri, 31 Mar 2006 21:32:57 +0200, Asterbing a écrit :
Par exemple, ici parfois $fileok devient zéro, alors que $file existe dans les faits.
if (! -e $file){$fileok = 0;}
Est-ce un pb de stabilité du -e ?
Sûrement pas.
Est-ce une syntaxe non standard du chemin (il vient d'un formulaire et je n'escape pas les "", devrais-je ?) ?
Oui, c'est capital. ne jamais faire confiance au contenu d'un formulaire; on peut très facilement taper du code perl dedans...
Par contre il vaut mieux utiliser les / à la place des , ça marchera beaucoup mieux, pas besoin d'échapper... Et utilise un module comme File::Spec pour nettoyer le chemin et le mettre au propre.
Il peut aussi y avoir des problèmes d'encodage (y a t'il des accents dans les chemins, ou des espaces?), ou de droits d'accès au fichier.
-- Si non confectus non reficiat.
Le Fri, 31 Mar 2006 21:32:57 +0200, Asterbing a écrit :
Par exemple, ici parfois $fileok devient zéro, alors que $file existe
dans les faits.
if (! -e $file){$fileok = 0;}
Est-ce un pb de stabilité du -e ?
Sûrement pas.
Est-ce une syntaxe non standard du chemin (il vient d'un formulaire et
je n'escape pas les "", devrais-je ?) ?
Oui, c'est capital. ne jamais faire confiance au contenu d'un formulaire;
on peut très facilement taper du code perl dedans...
Par contre il vaut mieux utiliser les / à la place des , ça marchera
beaucoup mieux, pas besoin d'échapper... Et utilise un module comme
File::Spec pour nettoyer le chemin et le mettre au propre.
Il peut aussi y avoir des problèmes d'encodage (y a t'il des accents
dans les chemins, ou des espaces?), ou de droits d'accès au fichier.
Le Fri, 31 Mar 2006 21:32:57 +0200, Asterbing a écrit :
Par exemple, ici parfois $fileok devient zéro, alors que $file existe dans les faits.
if (! -e $file){$fileok = 0;}
Est-ce un pb de stabilité du -e ?
Sûrement pas.
Est-ce une syntaxe non standard du chemin (il vient d'un formulaire et je n'escape pas les "", devrais-je ?) ?
Oui, c'est capital. ne jamais faire confiance au contenu d'un formulaire; on peut très facilement taper du code perl dedans...
Par contre il vaut mieux utiliser les / à la place des , ça marchera beaucoup mieux, pas besoin d'échapper... Et utilise un module comme File::Spec pour nettoyer le chemin et le mettre au propre.
Il peut aussi y avoir des problèmes d'encodage (y a t'il des accents dans les chemins, ou des espaces?), ou de droits d'accès au fichier.
-- Si non confectus non reficiat.
Asterbing
In article , says...
Oui, c'est capital. ne jamais faire confiance au contenu d'un formulaire; on peut très facilement taper du code perl dedans...
L'existence de ce fichier est en tête de traitement, alors rien ne se fera s'il n'est pas testé qu'il existe.
Par contre il vaut mieux utiliser les / à la place des , ça marchera beaucoup mieux, pas besoin d'échapper... Et utilise un module comme File::Spec pour nettoyer le chemin et le mettre au propre.
Je vois qu'il installé d'office avec Perl 5.008007 for MSWIN32, mais depuis quelle version l'est-il. La plus vieille version des serveurs visés par ce script est une 5.00503 sous FreeBSD et je ne peux pas installer de module supplémentaire (même pas en cgi-bin).
Il peut aussi y avoir des problèmes d'encodage (y a t'il des accents dans les chemins, ou des espaces?), ou de droits d'accès au fichier.
Non, pas d'accent à ce stade des tests. Par exemple il est arrivé au script d'échouer sur ce fichier test : "C:TESTstatshisto.gif".
Par contre, oui il pourrait très bien y avoir des accents : quel traitement devras-je faire subir à $file venant du formulaire dans ce cas ? Par exemple, imaginons : "C:Testéstatsrésultat_010406.gif"
In article <pan.2006.03.31.19.52.44.553415@imaginet.fr>,
eflorac@imaginet.fr says...
Oui, c'est capital. ne jamais faire confiance au contenu d'un formulaire;
on peut très facilement taper du code perl dedans...
L'existence de ce fichier est en tête de traitement, alors rien ne se
fera s'il n'est pas testé qu'il existe.
Par contre il vaut mieux utiliser les / à la place des , ça marchera
beaucoup mieux, pas besoin d'échapper... Et utilise un module comme
File::Spec pour nettoyer le chemin et le mettre au propre.
Je vois qu'il installé d'office avec Perl 5.008007 for MSWIN32, mais
depuis quelle version l'est-il. La plus vieille version des serveurs
visés par ce script est une 5.00503 sous FreeBSD et je ne peux pas
installer de module supplémentaire (même pas en cgi-bin).
Il peut aussi y avoir des problèmes d'encodage (y a t'il des accents
dans les chemins, ou des espaces?), ou de droits d'accès au fichier.
Non, pas d'accent à ce stade des tests. Par exemple il est arrivé au
script d'échouer sur ce fichier test : "C:TESTstatshisto.gif".
Par contre, oui il pourrait très bien y avoir des accents : quel
traitement devras-je faire subir à $file venant du formulaire dans ce
cas ? Par exemple, imaginons : "C:Testéstatsrésultat_010406.gif"
Oui, c'est capital. ne jamais faire confiance au contenu d'un formulaire; on peut très facilement taper du code perl dedans...
L'existence de ce fichier est en tête de traitement, alors rien ne se fera s'il n'est pas testé qu'il existe.
Par contre il vaut mieux utiliser les / à la place des , ça marchera beaucoup mieux, pas besoin d'échapper... Et utilise un module comme File::Spec pour nettoyer le chemin et le mettre au propre.
Je vois qu'il installé d'office avec Perl 5.008007 for MSWIN32, mais depuis quelle version l'est-il. La plus vieille version des serveurs visés par ce script est une 5.00503 sous FreeBSD et je ne peux pas installer de module supplémentaire (même pas en cgi-bin).
Il peut aussi y avoir des problèmes d'encodage (y a t'il des accents dans les chemins, ou des espaces?), ou de droits d'accès au fichier.
Non, pas d'accent à ce stade des tests. Par exemple il est arrivé au script d'échouer sur ce fichier test : "C:TESTstatshisto.gif".
Par contre, oui il pourrait très bien y avoir des accents : quel traitement devras-je faire subir à $file venant du formulaire dans ce cas ? Par exemple, imaginons : "C:Testéstatsrésultat_010406.gif"
Emmanuel Florac
Le Fri, 31 Mar 2006 22:11:05 +0200, Asterbing a écrit :
In article , says...
Oui, c'est capital. ne jamais faire confiance au contenu d'un formulaire; on peut très facilement taper du code perl dedans...
L'existence de ce fichier est en tête de traitement, alors rien ne se fera s'il n'est pas testé qu'il existe.
N'empèche qu'il faut toujours traiter une donnée "teintée". C'est le B-A-BA de la programmation sécurisée, ce qui fait la différence entre le code professionnel et la bidouille.
Par contre il vaut mieux utiliser les / à la place des , ça marchera beaucoup mieux, pas besoin d'échapper... Et utilise un module comme File::Spec pour nettoyer le chemin et le mettre au propre.
Je vois qu'il installé d'office avec Perl 5.008007 for MSWIN32, mais depuis quelle version l'est-il. La plus vieille version des serveurs visés par ce script est une 5.00503 sous FreeBSD et je ne peux pas installer de module supplémentaire (même pas en cgi-bin).
Quoi qu'il en soit le '/' est plus universel que le '' et beaucoup moins problématique.
Il peut aussi y avoir des problèmes d'encodage (y a t'il des accents dans les chemins, ou des espaces?), ou de droits d'accès au fichier.
Non, pas d'accent à ce stade des tests. Par exemple il est arrivé au script d'échouer sur ce fichier test : "C:TESTstatshisto.gif".
Ma boule de cristal est en panne. Quel est le code avant? L'utilisateur apache a t'il le droit de lire le fichier ?
Par contre, oui il pourrait très bien y avoir des accents : quel traitement devras-je faire subir à $file venant du formulaire dans ce cas ? Par exemple, imaginons : "C:Testéstatsrésultat_010406.gif"
Ça dépend de l'encodage de la page web source, de l'encodage du système de fichier windows (qui dépend en partie de la version de l'OS), et des modules utilisés par le code perl.
-- Si non confectus non reficiat.
Le Fri, 31 Mar 2006 22:11:05 +0200, Asterbing a écrit :
In article <pan.2006.03.31.19.52.44.553415@imaginet.fr>,
eflorac@imaginet.fr says...
Oui, c'est capital. ne jamais faire confiance au contenu d'un formulaire;
on peut très facilement taper du code perl dedans...
L'existence de ce fichier est en tête de traitement, alors rien ne se
fera s'il n'est pas testé qu'il existe.
N'empèche qu'il faut toujours traiter une donnée "teintée". C'est le
B-A-BA de la programmation sécurisée, ce qui fait la différence entre
le code professionnel et la bidouille.
Par contre il vaut mieux utiliser les / à la place des , ça marchera
beaucoup mieux, pas besoin d'échapper... Et utilise un module comme
File::Spec pour nettoyer le chemin et le mettre au propre.
Je vois qu'il installé d'office avec Perl 5.008007 for MSWIN32, mais
depuis quelle version l'est-il. La plus vieille version des serveurs
visés par ce script est une 5.00503 sous FreeBSD et je ne peux pas
installer de module supplémentaire (même pas en cgi-bin).
Quoi qu'il en soit le '/' est plus universel que le '' et beaucoup moins
problématique.
Il peut aussi y avoir des problèmes d'encodage (y a t'il des accents
dans les chemins, ou des espaces?), ou de droits d'accès au fichier.
Non, pas d'accent à ce stade des tests. Par exemple il est arrivé au
script d'échouer sur ce fichier test : "C:TESTstatshisto.gif".
Ma boule de cristal est en panne. Quel est le code avant? L'utilisateur
apache a t'il le droit de lire le fichier ?
Par contre, oui il pourrait très bien y avoir des accents : quel
traitement devras-je faire subir à $file venant du formulaire dans ce
cas ? Par exemple, imaginons : "C:Testéstatsrésultat_010406.gif"
Ça dépend de l'encodage de la page web source, de l'encodage du système
de fichier windows (qui dépend en partie de la version de l'OS), et des
modules utilisés par le code perl.
Le Fri, 31 Mar 2006 22:11:05 +0200, Asterbing a écrit :
In article , says...
Oui, c'est capital. ne jamais faire confiance au contenu d'un formulaire; on peut très facilement taper du code perl dedans...
L'existence de ce fichier est en tête de traitement, alors rien ne se fera s'il n'est pas testé qu'il existe.
N'empèche qu'il faut toujours traiter une donnée "teintée". C'est le B-A-BA de la programmation sécurisée, ce qui fait la différence entre le code professionnel et la bidouille.
Par contre il vaut mieux utiliser les / à la place des , ça marchera beaucoup mieux, pas besoin d'échapper... Et utilise un module comme File::Spec pour nettoyer le chemin et le mettre au propre.
Je vois qu'il installé d'office avec Perl 5.008007 for MSWIN32, mais depuis quelle version l'est-il. La plus vieille version des serveurs visés par ce script est une 5.00503 sous FreeBSD et je ne peux pas installer de module supplémentaire (même pas en cgi-bin).
Quoi qu'il en soit le '/' est plus universel que le '' et beaucoup moins problématique.
Il peut aussi y avoir des problèmes d'encodage (y a t'il des accents dans les chemins, ou des espaces?), ou de droits d'accès au fichier.
Non, pas d'accent à ce stade des tests. Par exemple il est arrivé au script d'échouer sur ce fichier test : "C:TESTstatshisto.gif".
Ma boule de cristal est en panne. Quel est le code avant? L'utilisateur apache a t'il le droit de lire le fichier ?
Par contre, oui il pourrait très bien y avoir des accents : quel traitement devras-je faire subir à $file venant du formulaire dans ce cas ? Par exemple, imaginons : "C:Testéstatsrésultat_010406.gif"
Ça dépend de l'encodage de la page web source, de l'encodage du système de fichier windows (qui dépend en partie de la version de l'OS), et des modules utilisés par le code perl.
-- Si non confectus non reficiat.
Asterbing
In article , says...
Bonjour. Sous ActivePerl/Apache2/Win2k, quelquefois (pas tjrs donc) le test d'existence d'un fichier échoue alors que le chemin est correct.
Pour faciliter le test, voici un script abrégé qui échoue parfois sur certaines stations WIN32 d'un LAN, alors que ledit fichier existe bel et bien dans le chemin donné pour cette station.
#!/usr/bin/perl use strict; print "Content-type: text/htmlnn"; my $file = "C:TESTstatshisto.gif"; if (! -e $file){ print $file." not found"; } else { print $file." found"; } exit 0;
In article <MPG.1e97a258a1c807989897bb@news.tiscali.fr>, no@thanks.com
says...
Bonjour. Sous ActivePerl/Apache2/Win2k, quelquefois (pas tjrs donc) le
test d'existence d'un fichier échoue alors que le chemin est correct.
Pour faciliter le test, voici un script abrégé qui échoue parfois sur
certaines stations WIN32 d'un LAN, alors que ledit fichier existe bel et
bien dans le chemin donné pour cette station.
#!/usr/bin/perl
use strict;
print "Content-type: text/htmlnn";
my $file = "C:\TEST\stats\histo.gif";
if (! -e $file){ print $file." not found"; }
else { print $file." found"; }
exit 0;
Bonjour. Sous ActivePerl/Apache2/Win2k, quelquefois (pas tjrs donc) le test d'existence d'un fichier échoue alors que le chemin est correct.
Pour faciliter le test, voici un script abrégé qui échoue parfois sur certaines stations WIN32 d'un LAN, alors que ledit fichier existe bel et bien dans le chemin donné pour cette station.
#!/usr/bin/perl use strict; print "Content-type: text/htmlnn"; my $file = "C:TESTstatshisto.gif"; if (! -e $file){ print $file." not found"; } else { print $file." found"; } exit 0;
Asterbing
In article , says...
Le Fri, 31 Mar 2006 22:11:05 +0200, Asterbing a écrit :
In article , L'existence de ce fichier est en tête de traitement, alors rien ne se fera s'il n'est pas testé qu'il existe.
N'empèche qu'il faut toujours traiter une donnée "teintée". C'est le B-A-BA de la programmation sécurisée, ce qui fait la différence entre le code professionnel et la bidouille.
OK, je retiens.
visés par ce script est une 5.00503 sous FreeBSD et je ne peux pas installer de module supplémentaire (même pas en cgi-bin).
Quoi qu'il en soit le '/' est plus universel que le '' et beaucoup moins problématique.
Bon, je note donc de remplacer ça : pas ce soir.
Ma boule de cristal est en panne. Quel est le code avant? L'utilisateur apache a t'il le droit de lire le fichier ?
Je viens justement de faire un micro script qui reproduit le pb : posté ailleurs dans le fil (pour évityer de le mettre à deux endroits).
Ça dépend de l'encodage de la page web source, de l'encodage du système de fichier windows (qui dépend en partie de la version de l'OS), et des modules utilisés par le code perl.
La page web source est en iso-8859 ou utf-8. Le pb a été vu sur des stations en Windows 200 Pro (5.00.2195) SP4, avec paramètre régionaux généraux et input en FR.
In article <pan.2006.03.31.20.29.04.193010@imaginet.fr>,
eflorac@imaginet.fr says...
Le Fri, 31 Mar 2006 22:11:05 +0200, Asterbing a écrit :
In article <pan.2006.03.31.19.52.44.553415@imaginet.fr>,
L'existence de ce fichier est en tête de traitement, alors rien ne se
fera s'il n'est pas testé qu'il existe.
N'empèche qu'il faut toujours traiter une donnée "teintée". C'est le
B-A-BA de la programmation sécurisée, ce qui fait la différence entre
le code professionnel et la bidouille.
OK, je retiens.
visés par ce script est une 5.00503 sous FreeBSD et je ne peux pas
installer de module supplémentaire (même pas en cgi-bin).
Quoi qu'il en soit le '/' est plus universel que le '' et beaucoup moins
problématique.
Bon, je note donc de remplacer ça : pas ce soir.
Ma boule de cristal est en panne. Quel est le code avant? L'utilisateur
apache a t'il le droit de lire le fichier ?
Je viens justement de faire un micro script qui reproduit le pb : posté
ailleurs dans le fil (pour évityer de le mettre à deux endroits).
Ça dépend de l'encodage de la page web source, de l'encodage du système
de fichier windows (qui dépend en partie de la version de l'OS), et des
modules utilisés par le code perl.
La page web source est en iso-8859 ou utf-8. Le pb a été vu sur des
stations en Windows 200 Pro (5.00.2195) SP4, avec paramètre régionaux
généraux et input en FR.
Le Fri, 31 Mar 2006 22:11:05 +0200, Asterbing a écrit :
In article , L'existence de ce fichier est en tête de traitement, alors rien ne se fera s'il n'est pas testé qu'il existe.
N'empèche qu'il faut toujours traiter une donnée "teintée". C'est le B-A-BA de la programmation sécurisée, ce qui fait la différence entre le code professionnel et la bidouille.
OK, je retiens.
visés par ce script est une 5.00503 sous FreeBSD et je ne peux pas installer de module supplémentaire (même pas en cgi-bin).
Quoi qu'il en soit le '/' est plus universel que le '' et beaucoup moins problématique.
Bon, je note donc de remplacer ça : pas ce soir.
Ma boule de cristal est en panne. Quel est le code avant? L'utilisateur apache a t'il le droit de lire le fichier ?
Je viens justement de faire un micro script qui reproduit le pb : posté ailleurs dans le fil (pour évityer de le mettre à deux endroits).
Ça dépend de l'encodage de la page web source, de l'encodage du système de fichier windows (qui dépend en partie de la version de l'OS), et des modules utilisés par le code perl.
La page web source est en iso-8859 ou utf-8. Le pb a été vu sur des stations en Windows 200 Pro (5.00.2195) SP4, avec paramètre régionaux généraux et input en FR.
Asterbing
In article , says...
Bonjour. Sous ActivePerl/Apache2/Win2k, quelquefois (pas tjrs donc) le test d'existence d'un fichier échoue alors que le chemin est correct.
Pour faciliter le test, voici un script abrégé qui échoue parfois sur certaines stations WIN32 d'un LAN, alors que ledit fichier existe bel et bien dans le chemin donné pour cette station.
Selon les conseil d'Emmanuel F. cela devient donc du mode taint et avec conversion des "" en "/". Le problème est néanmoins tjrs là.
#!/usr/bin/perl -T use strict; print "Content-type: text/htmlnn"; my $file = "C:/TEST/stats/histo.gif"; if (! -e $file){ print $file." not found"; } else { print $file." found"; } exit 0;
In article <MPG.1e97afee99526c539897bf@news.tiscali.fr>, no@thanks.com
says...
Bonjour. Sous ActivePerl/Apache2/Win2k, quelquefois (pas tjrs donc) le
test d'existence d'un fichier échoue alors que le chemin est correct.
Pour faciliter le test, voici un script abrégé qui échoue parfois sur
certaines stations WIN32 d'un LAN, alors que ledit fichier existe bel et
bien dans le chemin donné pour cette station.
Selon les conseil d'Emmanuel F. cela devient donc du mode taint et avec
conversion des "" en "/". Le problème est néanmoins tjrs là.
#!/usr/bin/perl -T
use strict;
print "Content-type: text/htmlnn";
my $file = "C:/TEST/stats/histo.gif";
if (! -e $file){ print $file." not found"; }
else { print $file." found"; }
exit 0;
Bonjour. Sous ActivePerl/Apache2/Win2k, quelquefois (pas tjrs donc) le test d'existence d'un fichier échoue alors que le chemin est correct.
Pour faciliter le test, voici un script abrégé qui échoue parfois sur certaines stations WIN32 d'un LAN, alors que ledit fichier existe bel et bien dans le chemin donné pour cette station.
Selon les conseil d'Emmanuel F. cela devient donc du mode taint et avec conversion des "" en "/". Le problème est néanmoins tjrs là.
#!/usr/bin/perl -T use strict; print "Content-type: text/htmlnn"; my $file = "C:/TEST/stats/histo.gif"; if (! -e $file){ print $file." not found"; } else { print $file." found"; } exit 0;
Emmanuel Florac
Le Fri, 31 Mar 2006 22:51:29 +0200, Asterbing a écrit :
#!/usr/bin/perl -T use strict; print "Content-type: text/htmlnn"; my $file = "C:/TEST/stats/histo.gif"; if (! -e $file){ print $file." not found"; } else { print $file." found"; } exit 0;
Les sont inutiles avant les '/', c'est tout l'intérêt d'employer des '/' justement :) Sinon qui crée le fichier ? Quels sont les droits détaillés dessus ?
-- Pluralitas non est ponenda sine necessitate. Guillaume d'Ockham.
Le Fri, 31 Mar 2006 22:51:29 +0200, Asterbing a écrit :
#!/usr/bin/perl -T
use strict;
print "Content-type: text/htmlnn";
my $file = "C:/TEST/stats/histo.gif";
if (! -e $file){ print $file." not found"; }
else { print $file." found"; }
exit 0;
Les sont inutiles avant les '/', c'est tout l'intérêt d'employer des
'/' justement :)
Sinon qui crée le fichier ? Quels sont les droits détaillés dessus ?
--
Pluralitas non est ponenda sine necessitate.
Guillaume d'Ockham.
Le Fri, 31 Mar 2006 22:51:29 +0200, Asterbing a écrit :
#!/usr/bin/perl -T use strict; print "Content-type: text/htmlnn"; my $file = "C:/TEST/stats/histo.gif"; if (! -e $file){ print $file." not found"; } else { print $file." found"; } exit 0;
Les sont inutiles avant les '/', c'est tout l'intérêt d'employer des '/' justement :) Sinon qui crée le fichier ? Quels sont les droits détaillés dessus ?
-- Pluralitas non est ponenda sine necessitate. Guillaume d'Ockham.
Asterbing
In article , says...
Les sont inutiles avant les '/', c'est tout l'intérêt d'employer des '/' justement :) Sinon qui crée le fichier ? Quels sont les droits détaillés dessus ?
D'accord pour le sans avant / !
Les fichiers sont créés - soit par d'autres softs locaux (sur la station même) - soit uploadés par d'autre stations via FTP vers serveur Serv-U
Les stations Windows sont en Win2K. Les fichiers sont sur unités en NTFS ou FAT32. L'utilisateur est loggé en administrateur au moment de la manip et peut normalement les lire et écrire.
In article <pan.2006.04.01.08.33.50.863490@imaginet.fr>,
eflorac@imaginet.fr says...
Les sont inutiles avant les '/', c'est tout l'intérêt d'employer des
'/' justement :)
Sinon qui crée le fichier ? Quels sont les droits détaillés dessus ?
D'accord pour le sans avant / !
Les fichiers sont créés
- soit par d'autres softs locaux (sur la station même)
- soit uploadés par d'autre stations via FTP vers serveur Serv-U
Les stations Windows sont en Win2K. Les fichiers sont sur unités en NTFS
ou FAT32. L'utilisateur est loggé en administrateur au moment de la
manip et peut normalement les lire et écrire.
Les sont inutiles avant les '/', c'est tout l'intérêt d'employer des '/' justement :) Sinon qui crée le fichier ? Quels sont les droits détaillés dessus ?
D'accord pour le sans avant / !
Les fichiers sont créés - soit par d'autres softs locaux (sur la station même) - soit uploadés par d'autre stations via FTP vers serveur Serv-U
Les stations Windows sont en Win2K. Les fichiers sont sur unités en NTFS ou FAT32. L'utilisateur est loggé en administrateur au moment de la manip et peut normalement les lire et écrire.
Emmanuel Florac
Le Sat, 01 Apr 2006 12:26:38 +0200, Asterbing a écrit :
Les stations Windows sont en Win2K. Les fichiers sont sur unités en NTFS ou FAT32. L'utilisateur est loggé en administrateur au moment de la manip et peut normalement les lire et écrire.
Oui mais le script est lancé par l'utilisateur sous lequel tourne apache, qui a probablement des droits très limités. Quel est l'utilisateur qui fait tourner le serveur apache ? Dans quels groupes est il ? Quels sont les droits sur les fichiers problématiques ? Par quels utilisateurs et groupes sont ils lisibles ?
-- Toutes les organisations ont leur règles, et les Femmes Algériennes doivent avoir aussi leurs règles. Aït Ahmed.
Le Sat, 01 Apr 2006 12:26:38 +0200, Asterbing a écrit :
Les stations Windows sont en Win2K. Les fichiers sont sur unités en NTFS
ou FAT32. L'utilisateur est loggé en administrateur au moment de la
manip et peut normalement les lire et écrire.
Oui mais le script est lancé par l'utilisateur sous lequel tourne apache,
qui a probablement des droits très limités. Quel est l'utilisateur qui
fait tourner le serveur apache ? Dans quels groupes est il ? Quels sont
les droits sur les fichiers problématiques ? Par quels utilisateurs et
groupes sont ils lisibles ?
--
Toutes les organisations ont leur règles, et les Femmes Algériennes
doivent avoir aussi leurs règles.
Aït Ahmed.
Le Sat, 01 Apr 2006 12:26:38 +0200, Asterbing a écrit :
Les stations Windows sont en Win2K. Les fichiers sont sur unités en NTFS ou FAT32. L'utilisateur est loggé en administrateur au moment de la manip et peut normalement les lire et écrire.
Oui mais le script est lancé par l'utilisateur sous lequel tourne apache, qui a probablement des droits très limités. Quel est l'utilisateur qui fait tourner le serveur apache ? Dans quels groupes est il ? Quels sont les droits sur les fichiers problématiques ? Par quels utilisateurs et groupes sont ils lisibles ?
-- Toutes les organisations ont leur règles, et les Femmes Algériennes doivent avoir aussi leurs règles. Aït Ahmed.
jl_morel
Dans l'article , a dit...
In article , says...
Bonjour. Sous ActivePerl/Apache2/Win2k, quelquefois (pas tjrs donc) le test d'existence d'un fichier échoue alors que le chemin est correct.
Pour faciliter le test, voici un script abrégé qui échoue parfois sur certaines stations WIN32 d'un LAN, alors que ledit fichier existe bel et bien dans le chemin donné pour cette station.
#!/usr/bin/perl use strict; print "Content-type: text/htmlnn"; my $file = "C:TESTstatshisto.gif"; if (! -e $file){ print $file." not found"; } else { print $file." found"; } exit 0;
Essayez quelque chose de plus proche du système en remplaçant les tests '-e $file' par 'GetAttributes($file, $_)' (C'est comme ça qu'on fait en C et c'est aussi plus rapide) :
#!/usr/bin/perl use strict; use Win32::File 'GetAttributes';
print "Content-type: text/htmlnn"; my $file = "C:TESTstatshisto.gif"; if (! GetAttributes($file, $_) ){ print $file." not found"; } else { print $file." found"; } exit 0;
et regardez si vous avez toujours des erreurs.
Le module Win32::File est normalement installé sur les Perl d'ActiveState au moins depuis la version 5.005
HTH
-- J-L.M. http://www.bribes.org/perl
Dans l'article <MPG.1e97afee99526c539897bf@news.tiscali.fr>, no@thanks.com a
dit...
In article <MPG.1e97a258a1c807989897bb@news.tiscali.fr>, no@thanks.com
says...
Bonjour. Sous ActivePerl/Apache2/Win2k, quelquefois (pas tjrs donc) le
test d'existence d'un fichier échoue alors que le chemin est correct.
Pour faciliter le test, voici un script abrégé qui échoue parfois sur
certaines stations WIN32 d'un LAN, alors que ledit fichier existe bel et
bien dans le chemin donné pour cette station.
#!/usr/bin/perl
use strict;
print "Content-type: text/htmlnn";
my $file = "C:\TEST\stats\histo.gif";
if (! -e $file){ print $file." not found"; }
else { print $file." found"; }
exit 0;
Essayez quelque chose de plus proche du système en remplaçant les tests
'-e $file' par 'GetAttributes($file, $_)'
(C'est comme ça qu'on fait en C et c'est aussi plus rapide) :
#!/usr/bin/perl
use strict;
use Win32::File 'GetAttributes';
print "Content-type: text/htmlnn";
my $file = "C:\TEST\stats\histo.gif";
if (! GetAttributes($file, $_) ){ print $file." not found"; }
else { print $file." found"; }
exit 0;
et regardez si vous avez toujours des erreurs.
Le module Win32::File est normalement installé sur les Perl d'ActiveState
au moins depuis la version 5.005
Bonjour. Sous ActivePerl/Apache2/Win2k, quelquefois (pas tjrs donc) le test d'existence d'un fichier échoue alors que le chemin est correct.
Pour faciliter le test, voici un script abrégé qui échoue parfois sur certaines stations WIN32 d'un LAN, alors que ledit fichier existe bel et bien dans le chemin donné pour cette station.
#!/usr/bin/perl use strict; print "Content-type: text/htmlnn"; my $file = "C:TESTstatshisto.gif"; if (! -e $file){ print $file." not found"; } else { print $file." found"; } exit 0;
Essayez quelque chose de plus proche du système en remplaçant les tests '-e $file' par 'GetAttributes($file, $_)' (C'est comme ça qu'on fait en C et c'est aussi plus rapide) :
#!/usr/bin/perl use strict; use Win32::File 'GetAttributes';
print "Content-type: text/htmlnn"; my $file = "C:TESTstatshisto.gif"; if (! GetAttributes($file, $_) ){ print $file." not found"; } else { print $file." found"; } exit 0;
et regardez si vous avez toujours des erreurs.
Le module Win32::File est normalement installé sur les Perl d'ActiveState au moins depuis la version 5.005
