Mon hébergeur ( Sivit mutualisé ) a le Safe Mode à On.
Celà implique des restrictions sur les fonctions, en particulier de
manipulation de fichiers.
Il me semblait avoir vu dans le PHP Manual sur le web, des
commentaires indiquant que pour faire une ouverture en écriture d'un
fichier sur le répertoire courant, il était mieux de faire d'abord un
touch($filename) puis en suite seulement un fopen($filename, "w").
Donc, mon instruction globale est la suivante:
if(!@touch($filename)||(!($fp = @fopen ($filename, "w")))
{
echo "Message d'erreur\n";
die(""); // Je pourrais
aussi bien mettre un exit;
}
Or, le script où se trouvent ces instructions, semble s'arrêter 1
fois sur 5 ou 6, sans créer le fichier $filename.
Le fichier $filename n'est pas accédé simultanément par un autre
script, seulement après par un autre script, qui s'aperçoit que le
fichier n'existe pas.
Je ne peux pas tester le message d'erreur, car le script est en
batch. Les errreurs sont imprévisibles.
Théoriquement, l'instruction $fp = @fopen($filename, "w") dans son
ensemble, rend la valeur de $fp d'après ce que je pense. Donc, je peux
grouper l'affectation et le test.
J'ai créé le répertoire courant et tous ses répertoires pères
manuellement, par le FTP.
Les permissions de tous les répertoires, sont au maximum de permissivité.
Je ne crée jamais de répertoire à partir d'un script PHP.
sauf si l'OS décide que touch = créer et donc que si le fichier existe, ça marche pas...
Étant donné que utime (la fonction cachée par touch) doit être conforme à SVr4 et POSIX.1-2001, ça me ferait bien mal. Et PHP n'utilises pas les flags ad hoc pour forcer le comportement que tu attends éventuellement.
sauf si l'OS décide que touch = créer et donc que si le fichier existe,
ça marche pas...
Étant donné que utime (la fonction cachée par touch) doit être
conforme à SVr4 et POSIX.1-2001, ça me ferait bien mal. Et PHP
n'utilises pas les flags ad hoc pour forcer le comportement que tu
attends éventuellement.
sauf si l'OS décide que touch = créer et donc que si le fichier existe, ça marche pas...
Étant donné que utime (la fonction cachée par touch) doit être conforme à SVr4 et POSIX.1-2001, ça me ferait bien mal. Et PHP n'utilises pas les flags ad hoc pour forcer le comportement que tu attends éventuellement.
D'après la documentation et le code source, l'âge du fichier n'est pas vérifié sur un touch. Donc ça renvoie true si tout se passe bien. sauf si l'OS décide que touch = créer et donc que si le fichier existe,
ça marche pas...
J'espère bien qu'il n'existe aucun O.S. de ce genre, ou que si PHP est porté sur un tel O.S. les développeurs auront l'intelligence de ne pas se faire avoir par le nom de cette commande et qu'ils en utiliseront une autre pour implémenter le touch() ! Mais personnellement ça me semblerait aussi stupide qu'un commande cd qui ferait rmdir, ou une commande date qui ferait reboot.
D'après la documentation et le code source, l'âge du fichier n'est pas
vérifié sur un touch. Donc ça renvoie true si tout se passe bien.
sauf si l'OS décide que touch = créer et donc que si le fichier existe,
ça marche pas...
J'espère bien qu'il n'existe aucun O.S. de ce genre, ou que si PHP est
porté sur un tel O.S. les développeurs auront l'intelligence de ne pas
se faire avoir par le nom de cette commande et qu'ils en utiliseront
une autre pour implémenter le touch() ! Mais personnellement ça me
semblerait aussi stupide qu'un commande cd qui ferait rmdir, ou une
commande date qui ferait reboot.
D'après la documentation et le code source, l'âge du fichier n'est pas vérifié sur un touch. Donc ça renvoie true si tout se passe bien. sauf si l'OS décide que touch = créer et donc que si le fichier existe,
ça marche pas...
J'espère bien qu'il n'existe aucun O.S. de ce genre, ou que si PHP est porté sur un tel O.S. les développeurs auront l'intelligence de ne pas se faire avoir par le nom de cette commande et qu'ils en utiliseront une autre pour implémenter le touch() ! Mais personnellement ça me semblerait aussi stupide qu'un commande cd qui ferait rmdir, ou une commande date qui ferait reboot.