j'utilise un composant System.IO.FileSystemWatcher pour surveiller la
création de nouveau fichier dans un Dossier. A l'appel de l'évènement
OnCreated j'essaye de lire le fichier modifier mais j'obtient parfois
une Exception.
Pour être plus précis l'Exception intervient au moment du contructeur.
"System.ArgumentException: Paramètre non valide utilisé."
try
{ BitmapSource = new System.Drawing.Bitmap(FileName);
}
catch( Exception e)
{
Debug.WriteLine(e.ToString());
return;
}
pourquoi cette exception? Y a t'il moyen de résoudre ce problème?
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
Paul Bacelar
"Alexandre" wrote in message news:41eea70d$0$16430$
Bonjour
j'utilise un composant System.IO.FileSystemWatcher pour surveiller la création de nouveau fichier dans un Dossier. A l'appel de l'évènement OnCreated j'essaye de lire le fichier modifier mais j'obtient parfois une Exception. Pour être plus précis l'Exception intervient au moment du contructeur. "System.ArgumentException: Paramètre non valide utilisé." try { BitmapSource = new System.Drawing.Bitmap(FileName); } catch( Exception e) { Debug.WriteLine(e.ToString()); return; } pourquoi cette exception? Y a t'il moyen de résoudre ce problème?
Merci pour vos idées
Alex
Quand vous êtes prévenu de la création d'un fichier, le programme qui a créé le fichier ne la pas forcement encore fermé.
Si votre programme réagis rapidement en essayant de lire le fichier, ce que fait le constructeur d'une Bitmap avec une string en paramètre, vous aurez une tentative de lecture sur un fichier verrouillé par le programme qui l'a crée.
Une méthode simple de contourner cette nuisance, c'est de ne rien faire au moment de la création d'un fichier mais au moment de son renommage.
Le renommage se fait sans verrouiller le fichier et est plus ou moins atomique. Le programme qui met le fichier dans le répertoire n'a qu'à le renommer juste après l'avoir fermer. Et votre programme d'écoute ne sera plus en race condition sur le fichier.
-- Paul Bacelar
"Alexandre" <tackel2000@free.fr> wrote in message
news:41eea70d$0$16430$636a15ce@news.free.fr...
Bonjour
j'utilise un composant System.IO.FileSystemWatcher pour surveiller la
création de nouveau fichier dans un Dossier. A l'appel de l'évènement
OnCreated j'essaye de lire le fichier modifier mais j'obtient parfois
une Exception.
Pour être plus précis l'Exception intervient au moment du contructeur.
"System.ArgumentException: Paramètre non valide utilisé."
try
{ BitmapSource = new System.Drawing.Bitmap(FileName);
}
catch( Exception e)
{
Debug.WriteLine(e.ToString());
return;
}
pourquoi cette exception? Y a t'il moyen de résoudre ce problème?
Merci pour vos idées
Alex
Quand vous êtes prévenu de la création d'un fichier, le programme qui a créé
le fichier ne la pas forcement encore fermé.
Si votre programme réagis rapidement en essayant de lire le fichier, ce que
fait le constructeur d'une Bitmap avec une string en paramètre, vous aurez
une tentative de lecture sur un fichier verrouillé par le programme qui l'a
crée.
Une méthode simple de contourner cette nuisance, c'est de ne rien faire au
moment de la création d'un fichier mais au moment de son renommage.
Le renommage se fait sans verrouiller le fichier et est plus ou moins
atomique. Le programme qui met le fichier dans le répertoire n'a qu'à le
renommer juste après l'avoir fermer. Et votre programme d'écoute ne sera
plus en race condition sur le fichier.
"Alexandre" wrote in message news:41eea70d$0$16430$
Bonjour
j'utilise un composant System.IO.FileSystemWatcher pour surveiller la création de nouveau fichier dans un Dossier. A l'appel de l'évènement OnCreated j'essaye de lire le fichier modifier mais j'obtient parfois une Exception. Pour être plus précis l'Exception intervient au moment du contructeur. "System.ArgumentException: Paramètre non valide utilisé." try { BitmapSource = new System.Drawing.Bitmap(FileName); } catch( Exception e) { Debug.WriteLine(e.ToString()); return; } pourquoi cette exception? Y a t'il moyen de résoudre ce problème?
Merci pour vos idées
Alex
Quand vous êtes prévenu de la création d'un fichier, le programme qui a créé le fichier ne la pas forcement encore fermé.
Si votre programme réagis rapidement en essayant de lire le fichier, ce que fait le constructeur d'une Bitmap avec une string en paramètre, vous aurez une tentative de lecture sur un fichier verrouillé par le programme qui l'a crée.
Une méthode simple de contourner cette nuisance, c'est de ne rien faire au moment de la création d'un fichier mais au moment de son renommage.
Le renommage se fait sans verrouiller le fichier et est plus ou moins atomique. Le programme qui met le fichier dans le répertoire n'a qu'à le renommer juste après l'avoir fermer. Et votre programme d'écoute ne sera plus en race condition sur le fichier.
-- Paul Bacelar
Paul Bacelar
Le move n'est pas forcement atomique, car il entraîne une copy et une suppression si la source et la destination sont sur des supports physiques différents. Et avec la généralisation des systèmes de fichiers dynamiques, une même lettre peut attendre des disques différents.
Donc, le move ne sera pas atomique et la notification de la création du fichier pourra intervenir avant la fin de la copy, donc retour à la case départ. Un renommage ne change pas la position physique du fichier et est donc plus à même d'être atomique. -- Paul Bacelar
"Benoit" wrote in message news:uWQn4Ls$
à moins de le créer dans un répertoire temporaire et faire un MOVE dans le dossier de destination.
Le move n'est pas forcement atomique, car il entraîne une copy et une
suppression si la source et la destination sont sur des supports physiques
différents. Et avec la généralisation des systèmes de fichiers dynamiques,
une même lettre peut attendre des disques différents.
Donc, le move ne sera pas atomique et la notification de la création du
fichier pourra intervenir avant la fin de la copy, donc retour à la case
départ. Un renommage ne change pas la position physique du fichier et est
donc plus à même d'être atomique.
--
Paul Bacelar
"Benoit" <techedPASDESPAM@laposte.net> wrote in message
news:uWQn4Ls$EHA.1260@TK2MSFTNGP12.phx.gbl...
à moins de le créer dans un répertoire temporaire et faire un MOVE dans le
dossier de destination.
Le move n'est pas forcement atomique, car il entraîne une copy et une suppression si la source et la destination sont sur des supports physiques différents. Et avec la généralisation des systèmes de fichiers dynamiques, une même lettre peut attendre des disques différents.
Donc, le move ne sera pas atomique et la notification de la création du fichier pourra intervenir avant la fin de la copy, donc retour à la case départ. Un renommage ne change pas la position physique du fichier et est donc plus à même d'être atomique. -- Paul Bacelar
"Benoit" wrote in message news:uWQn4Ls$
à moins de le créer dans un répertoire temporaire et faire un MOVE dans le dossier de destination.
Alexandre
Paul Bacelar a écrit :
Le move n'est pas forcement atomique, car il entraîne une copy et une suppression si la source et la destination sont sur des supports physiques différents. Et avec la généralisation des systèmes de fichiers dynamiques, une même lettre peut attendre des disques différents.
Donc, le move ne sera pas atomique et la notification de la création du fichier pourra intervenir avant la fin de la copy, donc retour à la case départ. Un renommage ne change pas la position physique du fichier et est donc plus à même d'être atomique.
Vous avez tout à fait raison. mais le renommage n'empêche pas le plantage. je l'ai testé.
Une autre idée par hazard?
Merci pour votre aide.
Alexandre
Paul Bacelar a écrit :
Le move n'est pas forcement atomique, car il entraîne une copy et une
suppression si la source et la destination sont sur des supports physiques
différents. Et avec la généralisation des systèmes de fichiers dynamiques,
une même lettre peut attendre des disques différents.
Donc, le move ne sera pas atomique et la notification de la création du
fichier pourra intervenir avant la fin de la copy, donc retour à la case
départ. Un renommage ne change pas la position physique du fichier et est
donc plus à même d'être atomique.
Vous avez tout à fait raison. mais le renommage n'empêche pas le
plantage. je l'ai testé.
Le move n'est pas forcement atomique, car il entraîne une copy et une suppression si la source et la destination sont sur des supports physiques différents. Et avec la généralisation des systèmes de fichiers dynamiques, une même lettre peut attendre des disques différents.
Donc, le move ne sera pas atomique et la notification de la création du fichier pourra intervenir avant la fin de la copy, donc retour à la case départ. Un renommage ne change pas la position physique du fichier et est donc plus à même d'être atomique.
Vous avez tout à fait raison. mais le renommage n'empêche pas le plantage. je l'ai testé.
Une autre idée par hazard?
Merci pour votre aide.
Alexandre
Paul Bacelar
"Alexandre" wrote in message news:41f13958$0$29107$
Paul Bacelar a écrit : > Le move n'est pas forcement atomique, car il entraîne une copy et une > suppression si la source et la destination sont sur des supports
physiques
> différents. Et avec la généralisation des systèmes de fichiers
dynamiques,
> une même lettre peut attendre des disques différents. > > Donc, le move ne sera pas atomique et la notification de la création du > fichier pourra intervenir avant la fin de la copy, donc retour à la case > départ. Un renommage ne change pas la position physique du fichier et
est
> donc plus à même d'être atomique.
Vous avez tout à fait raison. mais le renommage n'empêche pas le plantage. je l'ai testé.
Plantage? peut-on avoir la stacktrace?
Une autre idée par hazard?
Merci pour votre aide.
Alexandre
-- Paul Bacelar
"Alexandre" <tackel2000@free.fr> wrote in message
news:41f13958$0$29107$626a14ce@news.free.fr...
Paul Bacelar a écrit :
> Le move n'est pas forcement atomique, car il entraîne une copy et une
> suppression si la source et la destination sont sur des supports
physiques
> différents. Et avec la généralisation des systèmes de fichiers
dynamiques,
> une même lettre peut attendre des disques différents.
>
> Donc, le move ne sera pas atomique et la notification de la création du
> fichier pourra intervenir avant la fin de la copy, donc retour à la case
> départ. Un renommage ne change pas la position physique du fichier et
est
> donc plus à même d'être atomique.
Vous avez tout à fait raison. mais le renommage n'empêche pas le
plantage. je l'ai testé.
"Alexandre" wrote in message news:41f13958$0$29107$
Paul Bacelar a écrit : > Le move n'est pas forcement atomique, car il entraîne une copy et une > suppression si la source et la destination sont sur des supports
physiques
> différents. Et avec la généralisation des systèmes de fichiers
dynamiques,
> une même lettre peut attendre des disques différents. > > Donc, le move ne sera pas atomique et la notification de la création du > fichier pourra intervenir avant la fin de la copy, donc retour à la case > départ. Un renommage ne change pas la position physique du fichier et
est
> donc plus à même d'être atomique.
Vous avez tout à fait raison. mais le renommage n'empêche pas le plantage. je l'ai testé.
Plantage? peut-on avoir la stacktrace?
Une autre idée par hazard?
Merci pour votre aide.
Alexandre
-- Paul Bacelar
PePiCK
Bonjour Alexandre, J'utilise le FileSystemWatcher pour automatiser une compression de fichier qui sont copier dans certains dossiers pour fin de transfert au travers notre réseau (fichier de plus de 100mb distribués sur une quinzaine de serveurs). Donc pour contourner le problème du fichier qui n'est pas fini de créer, j'ai du faire quelque chose du genre avant de partir la compression. Jusqu'à maintenant, je n'ai eu aucun problème. Peut-être que ca peux t'aider !
private static void OnChanged( object source, FileSystemEventArgs e ) { switch( e.ChangeType ) { case WatcherChangeTypes.Changed: case WatcherChangeTypes.Created: if( FileIsAvailable( e.FullPath ) ) ... ... } }
"Alexandre" wrote in message news:41eea70d$0$16430$
Bonjour
j'utilise un composant System.IO.FileSystemWatcher pour surveiller la création de nouveau fichier dans un Dossier. A l'appel de l'évènement OnCreated j'essaye de lire le fichier modifier mais j'obtient parfois une Exception. Pour être plus précis l'Exception intervient au moment du contructeur. "System.ArgumentException: Paramètre non valide utilisé." try { BitmapSource = new System.Drawing.Bitmap(FileName); } catch( Exception e) { Debug.WriteLine(e.ToString()); return; } pourquoi cette exception? Y a t'il moyen de résoudre ce problème?
Merci pour vos idées
Alex
Bonjour Alexandre,
J'utilise le FileSystemWatcher pour automatiser une compression de fichier
qui sont copier dans certains dossiers pour fin de transfert au travers
notre réseau (fichier de plus de 100mb distribués sur une quinzaine de
serveurs). Donc pour contourner le problème du fichier qui n'est pas fini de
créer, j'ai du faire quelque chose du genre avant de partir la compression.
Jusqu'à maintenant, je n'ai eu aucun problème.
Peut-être que ca peux t'aider !
private static void OnChanged( object source, FileSystemEventArgs e )
{
switch( e.ChangeType )
{
case WatcherChangeTypes.Changed:
case WatcherChangeTypes.Created:
if( FileIsAvailable( e.FullPath ) )
...
...
}
}
"Alexandre" <tackel2000@free.fr> wrote in message
news:41eea70d$0$16430$636a15ce@news.free.fr...
Bonjour
j'utilise un composant System.IO.FileSystemWatcher pour surveiller la
création de nouveau fichier dans un Dossier. A l'appel de l'évènement
OnCreated j'essaye de lire le fichier modifier mais j'obtient parfois une
Exception.
Pour être plus précis l'Exception intervient au moment du contructeur.
"System.ArgumentException: Paramètre non valide utilisé."
try
{ BitmapSource = new System.Drawing.Bitmap(FileName);
}
catch( Exception e)
{
Debug.WriteLine(e.ToString());
return;
}
pourquoi cette exception? Y a t'il moyen de résoudre ce problème?
Bonjour Alexandre, J'utilise le FileSystemWatcher pour automatiser une compression de fichier qui sont copier dans certains dossiers pour fin de transfert au travers notre réseau (fichier de plus de 100mb distribués sur une quinzaine de serveurs). Donc pour contourner le problème du fichier qui n'est pas fini de créer, j'ai du faire quelque chose du genre avant de partir la compression. Jusqu'à maintenant, je n'ai eu aucun problème. Peut-être que ca peux t'aider !
private static void OnChanged( object source, FileSystemEventArgs e ) { switch( e.ChangeType ) { case WatcherChangeTypes.Changed: case WatcherChangeTypes.Created: if( FileIsAvailable( e.FullPath ) ) ... ... } }
"Alexandre" wrote in message news:41eea70d$0$16430$
Bonjour
j'utilise un composant System.IO.FileSystemWatcher pour surveiller la création de nouveau fichier dans un Dossier. A l'appel de l'évènement OnCreated j'essaye de lire le fichier modifier mais j'obtient parfois une Exception. Pour être plus précis l'Exception intervient au moment du contructeur. "System.ArgumentException: Paramètre non valide utilisé." try { BitmapSource = new System.Drawing.Bitmap(FileName); } catch( Exception e) { Debug.WriteLine(e.ToString()); return; } pourquoi cette exception? Y a t'il moyen de résoudre ce problème?
