J'ai un script PHP qui tourne et qui regarde si qqun a déposé un fichier sur
un serveur FTP.
Dès qu'un fichier est déposé, mon script l'ouvre en lecture et traite les
données.
Or, je me suis apercu qu'apparemment, mon script ouvre le fichier alors meme
que le transfert FTP soit fini. Donc, il ne contient pas toutes les données.
Comment voir s'il est utilisé ?
Merci !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
John Gallet
Bonjour,
Or, je me suis apercu qu'apparemment, mon script ouvre le fichier alors meme que le transfert FTP soit fini. Donc, il ne contient pas toutes les données.
Ultra classique. Tu as tout simplement oublié que transférer des données, ça prend du temps.
Comment voir s'il est utilisé ?
Beaucoup trop compliqué à faire par rapport à une autre solution simple. Il suffit de systématiquement transférer un fichier vide marquant la fin du transfert du fichier de données après son transfert. Tu scrutes ce fichier vide. Dès que tu le vois, tu le détruis. Puis tu traites ton fichier de données. Eventuellement tu peux te servir du fichier flag, de nom constant, pour véhiculer le nom du fichier à traiter et son format (compressé ou non par exemple).
Néanmoins, il y a probablement des bidouilles faisables en php, à grands coups de system/exec par exemple.
a++ JG
Bonjour,
Or, je me suis apercu qu'apparemment, mon script ouvre le fichier alors meme
que le transfert FTP soit fini. Donc, il ne contient pas toutes les données.
Ultra classique. Tu as tout simplement oublié que transférer des
données, ça prend du temps.
Comment voir s'il est utilisé ?
Beaucoup trop compliqué à faire par rapport à une autre solution simple.
Il suffit de systématiquement transférer un fichier vide marquant la fin
du transfert du fichier de données après son transfert. Tu scrutes ce
fichier vide. Dès que tu le vois, tu le détruis. Puis tu traites ton
fichier de données. Eventuellement tu peux te servir du fichier flag, de
nom constant, pour véhiculer le nom du fichier à traiter et son format
(compressé ou non par exemple).
Néanmoins, il y a probablement des bidouilles faisables en php, à grands
coups de system/exec par exemple.
Or, je me suis apercu qu'apparemment, mon script ouvre le fichier alors meme que le transfert FTP soit fini. Donc, il ne contient pas toutes les données.
Ultra classique. Tu as tout simplement oublié que transférer des données, ça prend du temps.
Comment voir s'il est utilisé ?
Beaucoup trop compliqué à faire par rapport à une autre solution simple. Il suffit de systématiquement transférer un fichier vide marquant la fin du transfert du fichier de données après son transfert. Tu scrutes ce fichier vide. Dès que tu le vois, tu le détruis. Puis tu traites ton fichier de données. Eventuellement tu peux te servir du fichier flag, de nom constant, pour véhiculer le nom du fichier à traiter et son format (compressé ou non par exemple).
Néanmoins, il y a probablement des bidouilles faisables en php, à grands coups de system/exec par exemple.
a++ JG
Stephane Pineau
Le 09 Jul 2004 15:03:59 GMT, John Gallet écrivait:
Beaucoup trop compliqué à faire par rapport à une autre solution simple. Il suffit de systématiquement transférer un fichier vide marquant la fin du transfert du fichier de données après son transfert.
C'est la 1ère idée qui m'est également venue, d'un autre côté demander l'envoi de deux fichiers dont l'un d'un nom précis ca risque d'être coton et sans garanti que le 2nd fichier sera tj envoyer. . La deuxième solution que j'envisagerai, vu qu'il doit s'agir d'un script tournant en daemon, c'est de * relever lorsqu'un nouveau fichier est détecté sa taille et la mémoriser, * au run suivant mettons toutes les 1mn (pas moins en tout cas) on relève de nouveau la taille, si elle a changé on mémoirise cette nouvelle valeur on considère que le fichier est tj en cours d'upload, on attend le run suivant * Si la taille n'a pas changé au bout de 2 run consécutifs on considère que le fichier est bon à traiter.
C'est à tester, parceque je ne sais pas ce que retourne comme taille la fonction qui va bien sur un fichier en cours de création (Sous Win je serais pas étonné qu'elle retourne tj 0 tant que le fichier n'est pas fermé, mais dans ce cas là ca simplfie le problème, puisque tant que la taille du fichier est à 0 on ne traite pas, point barre).
Le 09 Jul 2004 15:03:59 GMT, John Gallet <john.gallet@wanadoo.fr> écrivait:
Beaucoup trop compliqué à faire par rapport à une autre solution simple.
Il suffit de systématiquement transférer un fichier vide marquant la fin
du transfert du fichier de données après son transfert.
C'est la 1ère idée qui m'est également venue, d'un autre côté demander
l'envoi de deux fichiers dont l'un d'un nom précis ca risque d'être coton et
sans garanti que le 2nd fichier sera tj envoyer.
.
La deuxième solution que j'envisagerai, vu qu'il doit s'agir d'un script
tournant en daemon, c'est de
* relever lorsqu'un nouveau fichier est détecté sa taille et la mémoriser,
* au run suivant mettons toutes les 1mn (pas moins en tout cas) on relève de
nouveau la taille, si elle a changé on mémoirise cette nouvelle valeur on
considère que le fichier est tj en cours d'upload, on attend le run suivant
* Si la taille n'a pas changé au bout de 2 run consécutifs on considère que
le fichier est bon à traiter.
C'est à tester, parceque je ne sais pas ce que retourne comme taille la
fonction qui va bien sur un fichier en cours de création (Sous Win je serais
pas étonné qu'elle retourne tj 0 tant que le fichier n'est pas fermé, mais
dans ce cas là ca simplfie le problème, puisque tant que la taille du
fichier est à 0 on ne traite pas, point barre).
Le 09 Jul 2004 15:03:59 GMT, John Gallet écrivait:
Beaucoup trop compliqué à faire par rapport à une autre solution simple. Il suffit de systématiquement transférer un fichier vide marquant la fin du transfert du fichier de données après son transfert.
C'est la 1ère idée qui m'est également venue, d'un autre côté demander l'envoi de deux fichiers dont l'un d'un nom précis ca risque d'être coton et sans garanti que le 2nd fichier sera tj envoyer. . La deuxième solution que j'envisagerai, vu qu'il doit s'agir d'un script tournant en daemon, c'est de * relever lorsqu'un nouveau fichier est détecté sa taille et la mémoriser, * au run suivant mettons toutes les 1mn (pas moins en tout cas) on relève de nouveau la taille, si elle a changé on mémoirise cette nouvelle valeur on considère que le fichier est tj en cours d'upload, on attend le run suivant * Si la taille n'a pas changé au bout de 2 run consécutifs on considère que le fichier est bon à traiter.
C'est à tester, parceque je ne sais pas ce que retourne comme taille la fonction qui va bien sur un fichier en cours de création (Sous Win je serais pas étonné qu'elle retourne tj 0 tant que le fichier n'est pas fermé, mais dans ce cas là ca simplfie le problème, puisque tant que la taille du fichier est à 0 on ne traite pas, point barre).
C'est la 1ère idée qui m'est également venue, d'un autre côté demander l'envoi de deux fichiers dont l'un d'un nom précis ca risque d'être coton et
sans garanti que le 2nd fichier sera tj envoyer.
Ca tourne comme ça tous les jours de bourse ouvrés sur une quarantaine de site de productions que je connais pour 5 à 10 fichiers par jour depuis des années, on a jamais eu de problème lié à ce mécanisme.
* relever lorsqu'un nouveau fichier est détecté sa taille et la mémoriser, * au run suivant mettons toutes les 1mn (pas moins en tout cas) on relève de
nouveau la taille, si elle a changé on mémoirise cette nouvelle valeur on considère que le fichier est tj en cours d'upload, on attend le run suivant
* Si la taille n'a pas changé au bout de 2 run consécutifs on considère que le fichier est bon à traiter.
Et si manque de bol le transfert a échoué et est en cours de reprise, t'es à poil. Been there, done that, got the tshirt.
Si le gars qui te fait l'upload veut bien faire un touch du deuxième fichier, c'est beaucoup plus robuste. Du moment qu'il commence par un nom différent du fichier de data (préfixe constant), on peut ensuite le mettre dans un répertoire spécifique et se passer d'un nom constant, même si ça simplifie. De plus, ce n'est pas compliqué d'avoir toujours le même nom. Sinon, ta méthode est la moins pire en numéro deux.
a++ JG
Bonsoir,
C'est la 1ère idée qui m'est également venue, d'un autre côté demander
l'envoi de deux fichiers dont l'un d'un nom précis ca risque d'être coton
et
sans garanti que le 2nd fichier sera tj envoyer.
Ca tourne comme ça tous les jours de bourse ouvrés sur une quarantaine de
site de productions que je connais pour 5 à 10 fichiers par jour depuis des
années, on a jamais eu de problème lié à ce mécanisme.
* relever lorsqu'un nouveau fichier est détecté sa taille et la mémoriser,
* au run suivant mettons toutes les 1mn (pas moins en tout cas) on relève
de
nouveau la taille, si elle a changé on mémoirise cette nouvelle valeur on
considère que le fichier est tj en cours d'upload, on attend le run
suivant
* Si la taille n'a pas changé au bout de 2 run consécutifs on considère que
le fichier est bon à traiter.
Et si manque de bol le transfert a échoué et est en cours de reprise, t'es à
poil. Been there, done that, got the tshirt.
Si le gars qui te fait l'upload veut bien faire un touch du deuxième
fichier, c'est beaucoup plus robuste. Du moment qu'il commence par un nom
différent du fichier de data (préfixe constant), on peut ensuite le mettre
dans un répertoire spécifique et se passer d'un nom constant, même si ça
simplifie. De plus, ce n'est pas compliqué d'avoir toujours le même nom.
Sinon, ta méthode est la moins pire en numéro deux.
C'est la 1ère idée qui m'est également venue, d'un autre côté demander l'envoi de deux fichiers dont l'un d'un nom précis ca risque d'être coton et
sans garanti que le 2nd fichier sera tj envoyer.
Ca tourne comme ça tous les jours de bourse ouvrés sur une quarantaine de site de productions que je connais pour 5 à 10 fichiers par jour depuis des années, on a jamais eu de problème lié à ce mécanisme.
* relever lorsqu'un nouveau fichier est détecté sa taille et la mémoriser, * au run suivant mettons toutes les 1mn (pas moins en tout cas) on relève de
nouveau la taille, si elle a changé on mémoirise cette nouvelle valeur on considère que le fichier est tj en cours d'upload, on attend le run suivant
* Si la taille n'a pas changé au bout de 2 run consécutifs on considère que le fichier est bon à traiter.
Et si manque de bol le transfert a échoué et est en cours de reprise, t'es à poil. Been there, done that, got the tshirt.
Si le gars qui te fait l'upload veut bien faire un touch du deuxième fichier, c'est beaucoup plus robuste. Du moment qu'il commence par un nom différent du fichier de data (préfixe constant), on peut ensuite le mettre dans un répertoire spécifique et se passer d'un nom constant, même si ça simplifie. De plus, ce n'est pas compliqué d'avoir toujours le même nom. Sinon, ta méthode est la moins pire en numéro deux.
a++ JG
Marc
Rhikio wrote:
Bonjour,
J'ai un script PHP qui tourne et qui regarde si qqun a déposé un fichier sur un serveur FTP. Dès qu'un fichier est déposé, mon script l'ouvre en lecture et traite les données. Or, je me suis apercu qu'apparemment, mon script ouvre le fichier alors meme que le transfert FTP soit fini. Donc, il ne contient pas toutes les données. Comment voir s'il est utilisé ? Merci !
est-ce que ce n'est pas le cas typique de l'utilisation d'un verrou de fichier ? (flock) ?
Rhikio wrote:
Bonjour,
J'ai un script PHP qui tourne et qui regarde si qqun a déposé un fichier sur
un serveur FTP.
Dès qu'un fichier est déposé, mon script l'ouvre en lecture et traite les
données.
Or, je me suis apercu qu'apparemment, mon script ouvre le fichier alors meme
que le transfert FTP soit fini. Donc, il ne contient pas toutes les données.
Comment voir s'il est utilisé ?
Merci !
est-ce que ce n'est pas le cas typique de l'utilisation d'un verrou de
fichier ? (flock) ?
J'ai un script PHP qui tourne et qui regarde si qqun a déposé un fichier sur un serveur FTP. Dès qu'un fichier est déposé, mon script l'ouvre en lecture et traite les données. Or, je me suis apercu qu'apparemment, mon script ouvre le fichier alors meme que le transfert FTP soit fini. Donc, il ne contient pas toutes les données. Comment voir s'il est utilisé ? Merci !
est-ce que ce n'est pas le cas typique de l'utilisation d'un verrou de fichier ? (flock) ?
John Gallet
Re,
est-ce que ce n'est pas le cas typique de l'utilisation d'un verrou de fichier ? (flock) ?
Selon ce que j'en ai compris, le ficheir arrive en PUT depuis un serveur distant. Si on fait ça en GET depuis le serveur local, il n'est pas difficile de lancer le script php au bon moment.
Donc si tu arrives à garantir que l'application extérieure (sur unix (x)inetd passant la main à ftpd en l'occurence) l'utilisera comme toi, alors oui. Il faudrait faire un test avec un fichier méga-maousse-costaud pour avoir le temps de lancer le script tranquillement et de regarder comment c'est géré. Et revérifier le jour où tu changes d'OS... Bref, les verrous sur fichier c'est (parfois) bien mais surtout pour synchroniser des applications sur lesquelles tu as la main de bout en bout. Pour le reste j'ai un peu peur. Autre chose : vérifier que le lock est supprimé en cas de plantage du programme, et c'est pas nécessairement évident.
a++ JG
Re,
est-ce que ce n'est pas le cas typique de l'utilisation d'un verrou de
fichier ? (flock) ?
Selon ce que j'en ai compris, le ficheir arrive en PUT depuis un serveur
distant. Si on fait ça en GET depuis le serveur local, il n'est pas
difficile de lancer le script php au bon moment.
Donc si tu arrives à garantir que l'application extérieure (sur unix
(x)inetd passant la main à ftpd en l'occurence) l'utilisera comme toi,
alors oui. Il faudrait faire un test avec un fichier
méga-maousse-costaud pour avoir le temps de lancer le script
tranquillement et de regarder comment c'est géré. Et revérifier le jour
où tu changes d'OS... Bref, les verrous sur fichier c'est (parfois) bien
mais surtout pour synchroniser des applications sur lesquelles tu as la
main de bout en bout. Pour le reste j'ai un peu peur. Autre chose :
vérifier que le lock est supprimé en cas de plantage du programme, et
c'est pas nécessairement évident.
est-ce que ce n'est pas le cas typique de l'utilisation d'un verrou de fichier ? (flock) ?
Selon ce que j'en ai compris, le ficheir arrive en PUT depuis un serveur distant. Si on fait ça en GET depuis le serveur local, il n'est pas difficile de lancer le script php au bon moment.
Donc si tu arrives à garantir que l'application extérieure (sur unix (x)inetd passant la main à ftpd en l'occurence) l'utilisera comme toi, alors oui. Il faudrait faire un test avec un fichier méga-maousse-costaud pour avoir le temps de lancer le script tranquillement et de regarder comment c'est géré. Et revérifier le jour où tu changes d'OS... Bref, les verrous sur fichier c'est (parfois) bien mais surtout pour synchroniser des applications sur lesquelles tu as la main de bout en bout. Pour le reste j'ai un peu peur. Autre chose : vérifier que le lock est supprimé en cas de plantage du programme, et c'est pas nécessairement évident.
