[Linux-bruxelles] à cause d'une taille? Fwd:http://vinux.org.uk - Downloads - Latest - 2.0 - USB Edition(s)
Laurent Léonard
laurent at open-minds.org
Sam 12 Sep 20:57:31 CEST 2009
Le samedi 12 septembre 2009 à 19:56, Aldo a écrit :
> On Fri, Sep 11, 2009 at 11:19:44PM +0200, Laurent Léonard wrote:
> [...]
>
> > Si tu as accès au fichier fstab tu sauras quel est le système de fichier
> > utilisé. Mais vu que tu as posé des questions précédemment sur les droits
> > des fichiers, même si la supposition de son utilisation serait ridicule,
> > ça exclue vfat. À ma connaissance il n'y a pas de système de fichiers qui
> > prenne en charge la gestion des droits tout en ne prenant pas en charge
> > les fichiers de plus de 4 Go... De plus, même si c'était le cas, tu
> > n'aurais pas pu écrire la totalité de ton fichier !
>
> Mon collègue qui a en fait l'accompte là-bas en Angleterre a contacté le
> hosteur:
>
> <snip>
> As expected they were not very helpful. They say that there is no
> file size limit set and that if we want to make of the changes to the
> system you suggested we would have to pay for a dedicated server which
> I cannot afford. They also said that they thought it was more likely
> to be a PHP issue and that there is somekind of throttling policy that
> stops the downloads of very large files if it will eat up all of the
> bandwidth.
> We will just have to stick to
> the 2GB limit for now, which isn't a problem for me, and it will make
> other people making other versions think more carefully about what
> they want to include/exclude.
> </snip>
>
> Donc comme tu dis il reste le truc du hacking mais comme c pas moi qui
> avait écrit le code j'ai bcp de mal à savoir qu'en faire:
> si qq'un se sent donc d'attaque (qu'il prennen note des pintes de bière que
> je lui doit ultérieurement...), je colle l'orig.index.php et me fie à vos
> suggestions.
Ce n'est effectivement pas de la faute de l'hébergeur puisque cette limitation
est liée à PHP. Ca serait peut-être bien de lancer la question aux
développeurs de PHP pour connaître le statut du bug, il a pourtant été
signalé il y a longtemps : http://bugs.php.net/bug.php?id=27792 Mais ça
semble trainer malgré les différents patches proposés.
Pour la limitation de la taille, je peux encore comprendre qu'ils utilisent un
encodage sur 32 bits pour la valeur en octets, mais pourquoi ce même bug pour
les dates de création/modification/accès ?
Pour récupérer ces 4 valeurs, je ne vois qu'un appel à stat via exec() (voir
fichier modifié et patch en pièce jointe). Attention cependant à ne pas avoir
de fichier avec un nom contenant des espaces (j'imagine que ça ne sera pas le
cas), sinon il faudra les échapper évidemment.
--
Laurent Léonard
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: orig.index.php.patch
Type: text/x-diff
Taille: 710 octets
Desc: non disponible
URL: </pipermail/linux-bruxelles/attachments/20090912/f6031dc0/attachment-0002.patch>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: orig.index.stat.php
Type: application/x-php
Taille: 6078 octets
Desc: non disponible
URL: </pipermail/linux-bruxelles/attachments/20090912/f6031dc0/attachment-0002.bin>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 197 octets
Desc: This is a digitally signed message part.
URL: </pipermail/linux-bruxelles/attachments/20090912/f6031dc0/attachment-0001.sig>
Plus d'informations sur la liste de diffusion Linux-bruxelles