[spip-dev] Re[4]: [spip-commit]

Je pensais que link/unlink se référait aux droits du répertoire...

Pour la création, c'est en effet les droits du répertoire qui sont
pris en considération, mais pour la suppression, ce sont les droits du
fichier.

L'utilisateur courant dans un script PHP est celui qui fait tourner
Apache (si PHP est en module, tout du moins), c'est à dire par défaut
'www-data' ou 'nobody' sur les Linux.

Les fichiers envoyés par FTP appartiennent au compte de l'utilisateur,
c'est à dire un autre.

Donc même si le répertoire est en 'drwxrwxrwx', si le umask de
l'utilisateur fait qu'un fichier "posé" en FTP est en '-rw-r--r--',
PHP ne pourra pas le supprimer.

En plus, le répertoire peut appartenir soit à "apache" soit à "user"
suivant que l'install a été faite par FTP ou par 'spip_loader.php3',
donc ça conduit à des situations pénibles ... :wink:

-Nicolas

En plus, le répertoire peut appartenir soit à "apache" soit à "user"
suivant que l'install a été faite par FTP ou par 'spip_loader.php3',
donc ça conduit à des situations pénibles ... :wink:

Oui, mais au fait pourquoi est-ce qu'on parle de ça ? Lors de l'install, on
exige de passer en 777. Ensuite spip tente de supprimer les fichiers en
questions, mais s'il n'y arrive pas il ne se plaint pas... je n'ai pas
touché à ça dans mes modifs.

-- Fil

Oui, mais au fait pourquoi est-ce qu'on parle de ça ?

Euh, je sais pas, je suis arrivé en cours de route, quelqu'un parlait
de problèmes de droits, alors j'ai tenté d'expliquer, c'est tout ...

Lors de l'install, on exige de passer en 777.

Ce qui est un peu violent, il faudrait peut-être étudier ça de plus
prêt pour la suite.

Ensuite spip tente de supprimer les fichiers en questions, mais s'il
n'y arrive pas il ne se plaint pas...

Et du coup, upload ne se vide pas, et devient vite inutilisable, si
c'est la seule possibilité qu'on a. Bon, d'accord, ce n'est pas le cas
le plus courant ... :wink:

Y a-t'il quelque part un umask fixé pour l'upload, histoire qu'on ait
les droits suffisants via FTP pour écraser les documents ?

-Nicolas

> Ensuite spip tente de supprimer les fichiers en questions, mais s'il
> n'y arrive pas il ne se plaint pas...

Et du coup, upload ne se vide pas, et devient vite inutilisable, si
c'est la seule possibilité qu'on a. Bon, d'accord, ce n'est pas le cas
le plus courant ... :wink:

Si tu es capable d'uploader, tu peux aussi bien effacer à la main si
besoin...

Y a-t'il quelque part un umask fixé pour l'upload, histoire qu'on ait
les droits suffisants via FTP pour écraser les documents ?

je crois que tu confonds upload http et upload ftp. L'upload http ne pose
aucun problème. Nous parlons là (ecrire/upload/) de l'upload ftp.

-- Fil

Si tu es capable d'uploader, tu peux aussi bien effacer à la main si
besoin...

Tout à fait, mais c'est moins vrai quand il y a bon nombre de
contributeurs, qui doivent passer par l'admin pour uploader les
documents.

Imaginons qu'on soit obliger d'utiliser cette méthode sur uZine ... :wink:

Y a-t'il quelque part un umask fixé pour l'upload, histoire qu'on
ait les droits suffisants via FTP pour écraser les documents ?

je crois que tu confonds upload http et upload ftp.

Ah non, certainement pas !

L'upload http ne pose aucun problème.

L'upload non, mais les transferts FTP par la suite des documents
envoyés par upload HTTP, si.

Nous parlons là (ecrire/upload/) de l'upload ftp.

Oui, je sais bien, je parlais du "vrai" upload, par HTTP ... :wink:

-Nicolas