sur XP: tester si un fichier est completement écrit
5 réponses
OdarR
salut,
je cherche un moyen sur XP pour savoir si un fichier a fini d'=EAtre
=E9crit par
un autre programme, genre serveur FTP.
car je dois copier ce fichier ailleurs, mais pour l'instant, ma copie
ne donne
que un morceau de fichier. Je devrais attendre un peu que la copie se
termine,
mais combien de temps...?
il y a donc concurrence entre 2 process ind=E9pendants, sur un m=EAme
fichier physique.
est-ce que win32file (dans PyWin32) pourrait aider ??
Si l'écriture se fait en une (seule) fois, tu peux utiliser le DateTime du fichier, qui est mis à jour à la fermeture du fichier.
Si le fichier est écrit en plusieurs fois, il est impossible de deviner si un autre logiciel ne vas pas l'ouvrir à nouveau.
-- @-salutations
Michel Claveau
OdarR
On 25 mar, 17:05, MC wrote:
Bonjour !
Si l'écriture se fait en une (seule) fois, tu peux utiliser le DateTime du fichier, qui est mis à jour à la fermeture du fichier.
+1
Si le fichier est écrit en plusieurs fois, il est impossible de deviner si un autre logiciel ne vas pas l'ouvrir à nouveau.
ouaip. entretemps, je suis retourné dans mes recherches et ai jeté mon dévol u sur os.stat(<nom de fichier>), qui donne entre autres : taille, dates de création, modification, etc, bref une info assez complète dans un tuple.
Je teste cette valeur jusqu'à ce qu'elle ne change plus, avec un pas de 1 sec. ça a l'air de marcher :-) Mon script tourne ainsi sur Solaris et sur XP. (pas besoin du Mac ;-)
ps: j'ai cherché de la doc sur le PyWin32 et dont win32file fait partie (dis moi si je me trompe), mais elle semble quasi inexistante sur le web. C'est voulu ou quoi ? Même la doc intégrée au package semble très rare :-(
Olivier
On 25 mar, 17:05, MC <XX.X...@XX.XmclaveauX.com> wrote:
Bonjour !
Si l'écriture se fait en une (seule) fois, tu peux utiliser le DateTime
du fichier, qui est mis à jour à la fermeture du fichier.
+1
Si le fichier est écrit en plusieurs fois, il est impossible de deviner
si un autre logiciel ne vas pas l'ouvrir à nouveau.
ouaip.
entretemps, je suis retourné dans mes recherches et ai jeté mon dévol u
sur os.stat(<nom de fichier>), qui donne entre autres : taille, dates
de création, modification, etc,
bref une info assez complète dans un tuple.
Je teste cette valeur jusqu'à ce qu'elle ne change plus, avec un pas
de 1 sec.
ça a l'air de marcher :-)
Mon script tourne ainsi sur Solaris et sur XP. (pas besoin du Mac ;-)
ps: j'ai cherché de la doc sur le PyWin32 et dont win32file fait
partie (dis moi si je me trompe), mais elle semble quasi inexistante
sur le web.
C'est voulu ou quoi ?
Même la doc intégrée au package semble très rare :-(
Si l'écriture se fait en une (seule) fois, tu peux utiliser le DateTime du fichier, qui est mis à jour à la fermeture du fichier.
+1
Si le fichier est écrit en plusieurs fois, il est impossible de deviner si un autre logiciel ne vas pas l'ouvrir à nouveau.
ouaip. entretemps, je suis retourné dans mes recherches et ai jeté mon dévol u sur os.stat(<nom de fichier>), qui donne entre autres : taille, dates de création, modification, etc, bref une info assez complète dans un tuple.
Je teste cette valeur jusqu'à ce qu'elle ne change plus, avec un pas de 1 sec. ça a l'air de marcher :-) Mon script tourne ainsi sur Solaris et sur XP. (pas besoin du Mac ;-)
ps: j'ai cherché de la doc sur le PyWin32 et dont win32file fait partie (dis moi si je me trompe), mais elle semble quasi inexistante sur le web. C'est voulu ou quoi ? Même la doc intégrée au package semble très rare :-(
Olivier
Eric Masson
OdarR writes:
'Lut,
Je teste cette valeur jusqu'à ce qu'elle ne change plus, avec un pas de 1 sec. ça a l'air de marcher :-) Mon script tourne ainsi sur Solaris et sur XP. (pas besoin du Mac ;-)
Tu ouvres la porte aux race-conditions ;) Si le processus qui écrit dans le fichier est pour une raison ou une autre suspendu, tu ne le détecteras pas et ton traitement portera à nouveau sur une entrée incomplète.
ps: j'ai cherché de la doc sur le PyWin32 et dont win32file fait partie (dis moi si je me trompe), mais elle semble quasi inexistante sur le web.
Regarde chez Activestate.
Pour ton problème, je regarderais du coté des primitives de verrouillage type LockFileEx : http://msdn.microsoft.com/en-us/library/aa365203(VS.85).aspx Elle est exportée par win32file.
C'est dommage qu'il n'y ait pas l'équivalent du FileSystemWatcher de DotNet.
-- Bonjour je sais qu il existe un prog pour faire des cartes bancaires puis je l avoir par mail pas pour en fabriquer mais par curiosite merci a tous -+- LM In GNU : La cléf pour fabriquer un neuneu enfin dévoilée -+-
OdarR <Olivier.Darge@gmail.com> writes:
'Lut,
Je teste cette valeur jusqu'à ce qu'elle ne change plus, avec un pas
de 1 sec.
ça a l'air de marcher :-)
Mon script tourne ainsi sur Solaris et sur XP. (pas besoin du Mac ;-)
Tu ouvres la porte aux race-conditions ;)
Si le processus qui écrit dans le fichier est pour une raison ou une
autre suspendu, tu ne le détecteras pas et ton traitement portera à
nouveau sur une entrée incomplète.
ps: j'ai cherché de la doc sur le PyWin32 et dont win32file fait
partie (dis moi si je me trompe), mais elle semble quasi inexistante
sur le web.
Regarde chez Activestate.
Pour ton problème, je regarderais du coté des primitives de verrouillage
type LockFileEx :
http://msdn.microsoft.com/en-us/library/aa365203(VS.85).aspx
Elle est exportée par win32file.
C'est dommage qu'il n'y ait pas l'équivalent du FileSystemWatcher de
DotNet.
--
Bonjour je sais qu il existe un prog pour faire des cartes bancaires
puis je l avoir par mail pas pour en fabriquer mais par curiosite
merci a tous
-+- LM In GNU : La cléf pour fabriquer un neuneu enfin dévoilée -+-
Je teste cette valeur jusqu'à ce qu'elle ne change plus, avec un pas de 1 sec. ça a l'air de marcher :-) Mon script tourne ainsi sur Solaris et sur XP. (pas besoin du Mac ;-)
Tu ouvres la porte aux race-conditions ;) Si le processus qui écrit dans le fichier est pour une raison ou une autre suspendu, tu ne le détecteras pas et ton traitement portera à nouveau sur une entrée incomplète.
ps: j'ai cherché de la doc sur le PyWin32 et dont win32file fait partie (dis moi si je me trompe), mais elle semble quasi inexistante sur le web.
Regarde chez Activestate.
Pour ton problème, je regarderais du coté des primitives de verrouillage type LockFileEx : http://msdn.microsoft.com/en-us/library/aa365203(VS.85).aspx Elle est exportée par win32file.
C'est dommage qu'il n'y ait pas l'équivalent du FileSystemWatcher de DotNet.
-- Bonjour je sais qu il existe un prog pour faire des cartes bancaires puis je l avoir par mail pas pour en fabriquer mais par curiosite merci a tous -+- LM In GNU : La cléf pour fabriquer un neuneu enfin dévoilée -+-
OdarR
On 25 mar, 20:32, Eric Masson wrote:
Si le processus qui écrit dans le fichier est pour une raison ou une autre suspendu, tu ne le détecteras pas et ton traitement portera à nouveau sur une entrée incomplète.
oui juste. Mais sans pouvoir modifier l'envoyeur, je sais qui il est et je vois un peu les risques très limités encourus. :-) je vais réfléchir à la question, c'est sûr.
Regarde chez Activestate.
ah merci ! là, c'est plus complet. merci. que ferait-on sans AS...
Pour ton problème, je regarderais du coté des primitives de verrouill age type LockFileEx :http://msdn.microsoft.com/en-us/library/aa365203(VS.85). aspx Elle est exportée par win32file.
là ça intérresse celui qui crée..., pas celui qui consomme. si j'ai bien survolé :-) ça doit être plus subtil si tu m'en parles...faudra que je re-survole encore .
C'est dommage qu'il n'y ait pas l'équivalent du FileSystemWatcher de DotNet.
sais pas. tiens toi qui connait .NET est-ce que le comportement de VisualBasic avec les *Thread* a d'une façon ou d'une autre fondamentalement changé au passage à .NET ?? un portage d'une appli VB vers VB .NET semble poser quelques soucis à mon collègue...
Olivier
On 25 mar, 20:32, Eric Masson <e...@free.fr> wrote:
Si le processus qui écrit dans le fichier est pour une raison ou une
autre suspendu, tu ne le détecteras pas et ton traitement portera à
nouveau sur une entrée incomplète.
oui juste.
Mais sans pouvoir modifier l'envoyeur, je sais qui il est et je vois
un peu les risques
très limités encourus. :-)
je vais réfléchir à la question, c'est sûr.
Regarde chez Activestate.
ah merci ! là, c'est plus complet.
merci.
que ferait-on sans AS...
Pour ton problème, je regarderais du coté des primitives de verrouill age
type LockFileEx :http://msdn.microsoft.com/en-us/library/aa365203(VS.85). aspx
Elle est exportée par win32file.
là ça intérresse celui qui crée..., pas celui qui consomme.
si j'ai bien survolé :-)
ça doit être plus subtil si tu m'en parles...faudra que je re-survole
encore .
C'est dommage qu'il n'y ait pas l'équivalent du FileSystemWatcher de
DotNet.
sais pas.
tiens toi qui connait .NET est-ce que le comportement de VisualBasic
avec les *Thread*
a d'une façon ou d'une autre fondamentalement changé au passage
à .NET ??
un portage d'une appli VB vers VB .NET semble poser quelques soucis à
mon collègue...
Si le processus qui écrit dans le fichier est pour une raison ou une autre suspendu, tu ne le détecteras pas et ton traitement portera à nouveau sur une entrée incomplète.
oui juste. Mais sans pouvoir modifier l'envoyeur, je sais qui il est et je vois un peu les risques très limités encourus. :-) je vais réfléchir à la question, c'est sûr.
Regarde chez Activestate.
ah merci ! là, c'est plus complet. merci. que ferait-on sans AS...
Pour ton problème, je regarderais du coté des primitives de verrouill age type LockFileEx :http://msdn.microsoft.com/en-us/library/aa365203(VS.85). aspx Elle est exportée par win32file.
là ça intérresse celui qui crée..., pas celui qui consomme. si j'ai bien survolé :-) ça doit être plus subtil si tu m'en parles...faudra que je re-survole encore .
C'est dommage qu'il n'y ait pas l'équivalent du FileSystemWatcher de DotNet.
sais pas. tiens toi qui connait .NET est-ce que le comportement de VisualBasic avec les *Thread* a d'une façon ou d'une autre fondamentalement changé au passage à .NET ?? un portage d'une appli VB vers VB .NET semble poser quelques soucis à mon collègue...
Olivier
Eric Masson
OdarR writes:
'Lut,
oui juste. Mais sans pouvoir modifier l'envoyeur, je sais qui il est et je vois un peu les risques très limités encourus. :-)
C'est toi qui voit.
là ça intérresse celui qui crée..., pas celui qui consomme. si j'ai bien survolé :-) ça doit être plus subtil si tu m'en parles...faudra que je re-survole encore .
Le but serait de tenter de locker le fichier, et de ne pas traiter tant que le lock n'est pas accordé.
tiens toi qui connait .NET est-ce que le comportement de VisualBasic avec les *Thread* a d'une façon ou d'une autre fondamentalement changé au passage à .NET ??
Mes compétences en VB6 tiennent au dos d'un timbre poste, petit modèle, mais sjmsb, il n'y avait pas de support explicite des threads en VB6, juste des callbacks appelables par timer, non ?
-- Ceux qui ne sont pas d'accord, je n'en ai rien à foutre, adressez vous au comité en lui disant qu'il fallait continuer la discussion. je m'en fous totalement, le groupe est illisible, je ne le fréquente plus. -+- GA in <http://www.le-gnu.net> - Le monosensus pour les neuneux. -+-
OdarR <Olivier.Darge@gmail.com> writes:
'Lut,
oui juste.
Mais sans pouvoir modifier l'envoyeur, je sais qui il est et je vois
un peu les risques très limités encourus. :-)
C'est toi qui voit.
là ça intérresse celui qui crée..., pas celui qui consomme. si j'ai
bien survolé :-) ça doit être plus subtil si tu m'en parles...faudra
que je re-survole encore .
Le but serait de tenter de locker le fichier, et de ne pas traiter tant
que le lock n'est pas accordé.
tiens toi qui connait .NET est-ce que le comportement de VisualBasic
avec les *Thread* a d'une façon ou d'une autre fondamentalement changé
au passage à .NET ??
Mes compétences en VB6 tiennent au dos d'un timbre poste, petit modèle,
mais sjmsb, il n'y avait pas de support explicite des threads en VB6,
juste des callbacks appelables par timer, non ?
--
Ceux qui ne sont pas d'accord, je n'en ai rien à foutre, adressez vous
au comité en lui disant qu'il fallait continuer la discussion. je m'en
fous totalement, le groupe est illisible, je ne le fréquente plus.
-+- GA in <http://www.le-gnu.net> - Le monosensus pour les neuneux. -+-
oui juste. Mais sans pouvoir modifier l'envoyeur, je sais qui il est et je vois un peu les risques très limités encourus. :-)
C'est toi qui voit.
là ça intérresse celui qui crée..., pas celui qui consomme. si j'ai bien survolé :-) ça doit être plus subtil si tu m'en parles...faudra que je re-survole encore .
Le but serait de tenter de locker le fichier, et de ne pas traiter tant que le lock n'est pas accordé.
tiens toi qui connait .NET est-ce que le comportement de VisualBasic avec les *Thread* a d'une façon ou d'une autre fondamentalement changé au passage à .NET ??
Mes compétences en VB6 tiennent au dos d'un timbre poste, petit modèle, mais sjmsb, il n'y avait pas de support explicite des threads en VB6, juste des callbacks appelables par timer, non ?
-- Ceux qui ne sont pas d'accord, je n'en ai rien à foutre, adressez vous au comité en lui disant qu'il fallait continuer la discussion. je m'en fous totalement, le groupe est illisible, je ne le fréquente plus. -+- GA in <http://www.le-gnu.net> - Le monosensus pour les neuneux. -+-
