Discussion :

[jlg_47]

Bonjour,

J'ai v�velopp� un programme qui �crit des donn�es dans un fichier temporaire nomm� "output.tmp" ..

Quand on ferme le programme, je donne � l'utilisateur la possibilit� de sauvegarder ces donn�es en renommant le fichier et j'utilise le code suivant :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
if (saveFileDialog1->ShowDialog() == System::Windows::Forms::DialogResult::OK)
{
	String^ file_name = gcnew String("");
	file_name = saveFileDialog1->FileName::get();
	File::Move ("output.tmp",file_name);
}

Cela fonctionne si le nom du fichier donn� est nouveau.
Par contre si le fichier existe d�j�, �a plante m�me si on a r�pondu qu'on accepte de remplacer le fichier.

J'ai donc rajout� :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
 if (saveFileDialog1->ShowDialog() == System::Windows::Forms::DialogResult::OK)
{
	String^ file_name = gcnew String("");
	file_name = saveFileDialog1->FileName::get();
	if (File::Exists (file_name)) File::Delete (file_name);
	File::Move ("output.tmp",file_name);
}

Et �a plante toujours comme si l'instruction rajout�e n'�tait pas ex�cut�e ...

J'ai eu l'impression que Windows ex�cute le Move avant le Delete ...

Pour m'en assurer j'ai fait une horreur du genre :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
if (saveFileDialog1->ShowDialog() == System::Windows::Forms::DialogResult::OK)
{
        String^ file_name = gcnew String("");
	file_name = saveFileDialog1->FileName::get();
	if (File::Exists (file_name)) File::Delete (file_name);
	a: if (File::Exists (file_name)) goto a;
	File::Move ("output.tmp",file_name);
}

Et l� �a marche

J'ai donc plusieurs questions:

1- Pourquoi avec la forme simple le saveFileDialog ne d�truit pas lui m�me le fichier existant quand on lui dit qu'on accepte le remplacement?

2- Pourquoi le Move s'ex�cute apparemment avant le Delete?

3- Comment faire �a proprement?


Merci d'avance � ceux qui pourront �clairer ma pauvre lanterne.

Bonne journ�e.

[bacelar]

Comme je n�ai jamais �t� dou� pour les devinettes, moi je triche, je regarde la solution �crite � l'envers dans les Carambars.

Tr�ves de mise en boite.

Quand un programme plante, il y a un message d'erreur qui permet tr�s souvent de trouver la raison initiale du probl�me.

Donc, pouvez-vous nous donner le message d'erreur lors du plantage ?

[jlg_47]

Bonjour Paul,

Of course, with pleasure ...

Dans les cas 1 et 2, je re�ois le message suivant:

Unhandled exception.... bla bla bla ..

System.IO.IOException: Impossible de cr�er un fichier d�j� existant.

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.__Error.WinIOError()
at System.IO.File.Move(String sourceFileName, String destFileName)
at ....Form1.Appli_Close() in c:\........\form1.h:line 2230
at ....Form1.Form1_FormClosing(Object sender, FormClosingEventArgs e) in c:\.........\form1.h:line 2209
at System.Windows.Forms.Form.OnFormClosing(FormClosingEventArgs e)
at System.Windows.Forms.Form.WmClose(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

La ligne 2230 est la ligne

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

File::Move ("output.tmp",file_name);

qui se trouve juste apr�s :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

File::Delete (file_name);

Ce qui m'a fait penser qu'au moment o� le Move s'ex�cute, le Delete n'est pas encore ex�cut� ...

Et dans le cas 3, en rajoutant l'horrible boucle d'attente, �a marche sans probl�me mais je trouve �a horrible ...

On dirait qu'il faut laisser le temps � Windows de d�truire l'ancien fichier avant de faire le Move ..

[bacelar]

Sans certitudes, je pense � un probl�me de handler de fichier non ferm�, associ� � des actions d'"IO pending".

Je pense que votre "horrible" boucle finira par activer le garbage collector du Runtime.
Le garbage collector scanne les r�f�rences de variable et voit qu'une variable File n'est plus accessible.
Il enclenche le Finalize de l'objet.
Le Finalize d'un objet File ne fait que fermer/lib�rer l'handler de fichier Kernel du fichier.
En lib�rant le handler de fichier, le garbage collector permet aux autres actions "pending" sur le fichier de s'effectuer.
Un Delete de fichier est l'action "pending" par excellence, elle n'est ex�cut�e que tr�s rarement dans la foul� de la demande. On peut m�me attendre un reboot de la machine pour qu'il soit effectif, cas extr�mement fr�quent dans les installations de programmes "r�sidants" (la base de registre est un pr�cieux allier du syst�me dans ce cas).

Donc, le moyen pour infirmer ou affirmer mon hypoth�se, c'est de v�rifier que votre programme (ou un autre) n'a pas de handler sur le fichier au moment du Delete (via un outil type Process Explorer).

Si c'est bien le cas, c'est que vous g�rez mal le cycle de vie de vos objets de type File.

Il ne faut pas croire le discoure marketing sur le miracle du garbage collector, tout fichier ouvert doit �tre explicitement ferm� (le mot cl� "using" du C# est m�me une excellente initiative dans ce sens).

La fonctionnalit� que vous pr�sent� ressemble fort � des logs et .NET disposent d'outil bien plus puissant et simple que les primitives de fichier pour faire cela.

Entreprise Library (EntLib) dispose d'un ensemble de fonctionnalit� de log �norme. Il g�rera automatiquement le rolling des fichiers de logs, et cela sans la moindre ligne dans votre code autre que des primitives d'envoie de messages g�n�riques.