Lien absolu qui pointe la racine de Windows

Bonjour, je suis en train de développer un petit site à l'aide de uWamp mais je rencontre un problème : lorsque je fais

1
2

$file = fopen('/test.txt', 'w');
fclose($file);

le fichier n'arrive pas à être crée à cause d'un manque de permission. Or si le fichier existe à C:\test.txt alors il n'y a aucune erreur. J'aimerais savoir comment modifier les configurations de php ou d'apache pour que lorsque je tape '/test.txt' il me renvoie vers le dossier www qui sert de racine pour mon site.

Merci d'avance

Salut !

Où se trouvent les dossiers d'uWamp ?

Sur mon bureau C:\Users\Thomas\Desktop\uWamp

Question bête : est-ce que tu arrives à lire un fichier au même endroit que ton script si tu ajoutes un point avant le slash ?

Oui, sans problème

EDIT : je n'ai pas précisé mais j'utilise des virtual hosts

Donc c'est simplement parce que tu es sur un système Windows, mais que les chemins sont apparemment interprétés par PHP comme s'il s'agissait d'un système UNIX, donc un chemin /test.txt est considéré comme partant de la racine. Un simple test.txt ou la version "complète" ./test.txt permet de lire un fichier placé au même endroit que le script exécuté.

Normal

Et il n'y a pas moyen de configurer php ?

Je ne pense pas, mais pourquoi le voudrais-tu ?

En HTML aussi, quand tu lies une page depuis une autre et que les deux sont dans le même dossier, tu mets directement le nom de la page, pas de slash avant, sinon tu remontes à la racine du site. D'ailleurs, si tu mets un lien <a href="/">…</a>, il te mènera à la page d'accueil.
Pourquoi est-ce que pour le traitement des chemins en PHP tu voudrais un autre système ? Quel est le problème là-dessous ?

C'est bien le problème, j'aimerais utiliser le / pour remonter à la racine du site en PHP pour éviter de devoir taper des adresses relatives qui ressemblent à "../../../../resources/includes/page.php", mais le / me renvoie directement à la racine du disque dur.

Je connais cette variable superglobale mais j'aurais préféré une autre méthode. Dans tous les cas merci de m'avoir aidé.

Peut pas (peut être avec IIS ?) à moins d'être chrooté (systèmes Unixoïdes) sur celle-ci, ce qui pose d'autres problèmes (impossibilité de stocker des fichiers sensibles à un niveau supérieur pour empêcher qu'ils soient accessibles en HTTP).

Le plus simple et portable, à mon avis, c'est d'avoir un unique point d'entrée, ce qui permet d'utiliser du relatif partout (tout sera relatif au répertoire de ce script qui sert de point d'entrée de l'application). $_SERVER['DOCUMENT_ROOT'] c'est bien, mais encore faut-il que l'application soit installée en reprenant strictement la même arborescence sur chaque environnement et/ou il y a des situations où ça ne fonctionnera pas (sur Apache : du UserDir, les alias et VirtualDocumentRoot* pour Apache < 2.4.1 de mémoire).

Sinon, il faut voir. Par exemple, avec un autoload, tu peux te baser sur __DIR__ pour générer un chemin vers la racine (s'il n'y est pas déjà).

Dans le cas où il y a des étrangetés au niveau de la racine, je crois que $_SERVER contient aussi des informations à ce sujet, non ?

Et est-ce que realpath() pourrait aider dans le cas contraire ?

Dans le cas où il y a des étrangetés au niveau de la racine, je crois que $_SERVER contient aussi des informations à ce sujet, non ?

Oui et non : s'il y en a, au mieux, il faut savoir interpréter le contenu de $_SERVER. Pour un chroot, on le devine surtout à la tête des chemins. Je n'ai pas souvenir d'avoir déjà vu des trucs spéciaux dans $_SERVER par rapport à ce point.

Et est-ce que realpath() pourrait aider dans le cas contraire ?

Non. Je m'en servais par habitude quand je collais du relatif à __DIR__ mais pour autant que je sache, le système le gérerait très bien sans.

Donc un realpath($_SERVER['DOCUMENT_ROOT']) ne permettrait pas de retrouver, malgré le nom explicite de la fonction, le vrai chemin, en évitant les racines virtuelles, les dossiers utilisateurs et autres alias ?

Dommage…

Ah, non, ça ne résoudra pas chroot ni alias. Il faut dire que certaines choses comme les alias ou les VirtualDocumentRoot* relèvent du serveur HTTP. Pour les alias/userdir, ça va même au-delà, ça donne un chemin HTTP purement virtuel dont seul le serveur HTTP connaît la correspondance physique (chemin sur le système de fichiers). C'est encore deux choses bien différentes.

realpath ne permet que de (re)trouver le chemin absolu d'un fichier sur le système (en résolvant les éventuels liens symboliques qui composent ce chemin).

Si ton / pointe vers la racine de l'os (racine du disque dur utilisé sous windows, racine sous unix, … etc), c'est parfaitement normal ; en effet, cette notion définit "la racine", pas "la racine du serveur". En effet, en PHP, tu ne fais pas forcément que du dev serveur… Tu peux l'utiliser pour par exemple faire de la CLI.

Si tu veux absolument choper un fichier depuis l'endroit où tu te situes, il faut alors jouer avec __DIR__ et les chemins relatifs…

J'ai trouvé la fonction set_include_path() que j'ajoute à chacune de mes pages avec le chemin du dossier www, ce qui m'évite d'avoir à utiliser les chemins relatifs que je ne peux pas utiliser à cause des include.

Ce qui est une mauvaise pratique. Pourquoi ? Parce que tu n'aura pas forcément accès à l'appel de cette fonction.

Pourquoi ? Pour des raisons évidentes de sécurité. Le fait de faire appel à __DIR__ (en php 5.3+, ou bien dirname(__FILE__) en dessous… Même si faut le vouloir d'être en dessous) est beaucoup plus safe, car ici tu te situes par rapport au fichier où tu te trouves ; peu importe où tu te trouves, quand le fichier est appelé… etc.

Une autre astuce consiste à déclarer une constant ROOT, qui pointe depuis le fichier qui sert de point d'entrée. Mais ça, c'était bien avant l'avènement de la technque j'ai décrit plus haut…

Je n'aime pas trop utiliser des chemins relatifs, et je ne comprend pas trop les failles de sécurité pouvant découler de set_include_path(), excepté sur un serveur où php est partagé entre différents sites.