Bonne gestion des fichiers temporaires ?

**monstroplante** · 13/04/2008, 15h32

Bonjour à tous,

Je développe actuellement une petite application pour récupérer des pochètes d'albums MP3. cette application, développée en C#, télécharge de nombreuses images et les stock sous forme de fichiers temporaires. Je n'ai jamais travaillé avec des fichiers temporaires et je ne sais pas quels sont les bonnes pratiques à adopter.

Mes questions sont donc les suivantes :
-Quel répertoire serait le plus approprié pour stocker mes images
-Dois-je supprimer les images à la fermeture de mon application
-Si oui, quel événement de mon application pourrait être approprié pour déclencher le nettoyage (je crains que certains fichiers soient en cours d'utilisation...)

Merci pour votre aide !

**ram-0000** · 13/04/2008, 16h08

Envoyé par monstroplante

-Quel répertoire serait le plus approprié pour stocker mes images

Cela dépend de ton OS mais sous linux/unix, c'est /tmp et sous Microsoft, c'est le répertoire pointé par la variable d'environnement TEMP ou TMP. Après cela, tu as la fonction tmpnam() qui est utile pour générer des fichiers temporaires dans un répertoire donné (voir ici : http://man.he.net/man3/tmpnam)

Envoyé par monstroplante

-Dois-je supprimer les images à la fermeture de mon application

Je dirai oui mais cela dépend du contenu de tes fichiers. Si les refaire ne coûte rien, aloors clairement oui sinon, cela peut être des fichiers temporaires dont l'effacement à peu d'importance (genre les fichiers du cache internet local)

Envoyé par monstroplante

-Si oui, quel événement de mon application pourrait être approprié pour déclencher le nettoyage (je crains que certains fichiers soient en cours d'utilisation...)

Cela dépend de ton application, sous linux/unix, tu peux installer une fonction avec atexit()
pour faire le ménage (voir ici : http://www.linux-kheops.com/doc/man/.../atexit.3.html) sinom, pour une appli Windows, tu peux gérer l'événement WM_CLOSE

**monstroplante** · 17/04/2008, 01h48

Merci pour tes réponses. J'ai un peu avancé sur le problème et créé cette classe pour me faciliter les choses :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
	static class FileHelper {
		private static string _tempFolder;
		public static string TempFolder{
			get {
				if (_tempFolder == null) {
					_tempFolder = Path.Combine(Path.GetTempPath(),Guid.NewGuid().ToString());
					Directory.CreateDirectory(_tempFolder);
					Application.Current.Exit += new ExitEventHandler(Application_Exit);
				}
				return _tempFolder;
			}
		}
 
		public static string GetTempFileName() {
			return Path.Combine(TempFolder, Guid.NewGuid().ToString());
		}
 
 
		/// <summary>
		/// Supprime le dossier temporaire à la fermeture de l'application
		/// </summary>
		/// <param name="sender"></param>
		/// <param name="e"></param>
		static void Application_Exit(object sender, ExitEventArgs e) {
			Directory.Delete(_tempFolder,true);
		}
	}

Le problème c'est que, comme je le craignais, certains fichiers sont en cours d'utilisation à la fermeture du programme. Cela s'explique car je télécharge les images sur des thread différents qui sont, semble-il, encore actifs lors de l'événement "Exit" de l'application.

J'ai pensé utiliser l'attribut "DELETE_ON_CLOSE" mais je n'ai pas trouvé comment éditer les attributs "Extended" en C#.

Si vous avez un avis, une idée, je suis preneur (ce post serait peut être plus à sa place sur le forum c# ? si un modo passe par là...)

**Greybird** · 17/04/2008, 09h08

Oula, arrête tout.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Path.GetTempPath()

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Path.GetTempFileName()

**monstroplante** · 17/04/2008, 10h09

Oui, j'avais vu la méthode "Path.GetTempFileName()" mais je ne vois pas en quoi elle serait mieu adaptée car :
1) Elle ne gère en rien la suppression des fichiers temporaires. Ce qui est finalement mon seul vrai problème.
2) Elle crée un fichier vide, ce que ne souhaite pas.
3) Elle crée le fichier temporaire à la racine du répertoire temp or je préfère regrouper mes fichiers dans un sous-dossier car j'en utilise un grand nombre.

Finalement ma classe "FileHelper" me plait bien mais mon problème c'est que j'ai plusieurs background workers qui téléchargent des fichiers à l'aide de WebCilents. Je pense que c'est eux qui empèchent la suppression des fichiers à la fermeture de l'application.

(Cela peut paraitre étrange d'utiliser des WebClient avec des BackgroundWorkers mais je n'aprécie pas la méthode "DownloadFileAsync". Cette dernière ne travaile dans un thread séparé qu'après avoir résolu l'éventuel nom DNS contenu dans l'url. Ce qui entraine des lag sur le thread principal.)

PS : Merci pour le déplacement du post.

**Greybird** · 17/04/2008, 13h25

Envoyé par monstroplante

Oui, j'avais vu la méthode "Path.GetTempFileName()" mais je ne vois pas en quoi elle serait mieu adaptée car :
1) Elle ne gère en rien la suppression des fichiers temporaires. Ce qui est finalement mon seul vrai problème.
2) Elle crée un fichier vide, ce que ne souhaite pas.
3) Elle crée le fichier temporaire à la racine du répertoire temp or je préfère regrouper mes fichiers dans un sous-dossier car j'en utilise un grand nombre.

Ok, au temps pour moi, j'ai lu le post un peu rapidement qui plus est car tu faisais déjà utilisation de Path.GetTempPath()

Après ça me semble un peu bizarre de classer des fichiers temporaires, surtout s'ils ne doivent pas persister à la fin de l'application. Mais pourquoi pas.

L'idéal serait sans doute, avant de détruire le répertoire, de demander à tous tes threads de te terminer, et d'attendre que ce soit le cas. Cela suppose bien évidemment de conserver une liste de ces threads quelque part, mais j'imagine que c'est déjà le cas.

Mais au fond, pourquoi ne pas détruire ce que tu peux, et laisser le répertoire temporaire dans l'état où il se trouvera ? Le but de ce répertoire est bel et bien de servir de poubelle en cas de besoin, et, dans le cas où l'utilisateur aurait besoin de place, le système lui proposera de lui même de faire le ménage dans ce répertoire (en tout cas sous Windows)

Je conçois qu'il soit satisfaisant de faire le ménage derrière soi, mais est-ce vraiment grave de laisser quelques fichiers dans le répertoire temporaire, qui seront effacés si jamais le besoin s'en fait sentir ?

**smyley** · 17/04/2008, 18h33

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

FileStream fluxVersLeFichierTemporraire = new FileStream("Fichier Temporraire", FileMode.Create, FileAccess.ReadWrite, FileShare.None, 1024, FileOptions.DeleteOnClose);

On peut jouer avec FileShare pour utiliser le fichier via d'autres méthodes, mais il sera supprimé dès que le flux le sera, ou si le programme crash (même via un Kill dans le taskmgr)

**smyley** · 17/04/2008, 18h34

Envoyé par Greybird

Mais au fond, pourquoi ne pas détruire ce que tu peux, et laisser le répertoire temporaire dans l'état où il se trouvera ? Le but de ce répertoire est bel et bien de servir de poubelle en cas de besoin, et, dans le cas où l'utilisateur aurait besoin de place, le système lui proposera de lui même de faire le ménage dans ce répertoire (en tout cas sous Windows)

perso je trouve ça affreux !

**monstroplante** · 17/04/2008, 20h12

L'idéal serait sans doute, avant de détruire le répertoire, de demander à tous tes threads de te terminer, et d'attendre que ce soit le cas.

Oui, j'y ait pensé mais actuellement j'utilise des BackGroundWorkers qui, à ma connaissance n'offre pas la possibilité de mettre fin brutalement au thread. De plus, j'aimais bien le principe de ma classe "FileHelper" qui gérait de façon autonome la suppression des fichiers temporaires. Enfin, à étudier...

pourquoi ne pas détruire ce que tu peux, et laisser le répertoire temporaire dans l'état où il se trouvera ?

Je ferais peut etre ca si je ne trouve pas de solution simple. Mais dans ce cas, je céeras un dossier au nom constant pour pouvoir supprimer les fichiers résiduels lors de la prochaine éxécution du programme.

On peut jouer avec FileShare pour utiliser le fichier via d'autres méthodes, mais il sera supprimé dès que le flux le sera, ou si le programme crash (même via un Kill dans le taskmgr)

Il me semble que c'est à ce mécanisme que je fesait allusion en parlant de l'attribut "DELETE_ON_CLOSE". Est-il possible d'affecter ce "comportement" à un fichier existant ?? Si oui, ce serait l'idéal. Je m'explique : Je ne traite pas les filestream car je laisse des WebClients prendre en charge l'enregistrement des fichiers sur le disque. Je ne veut pas garder de handle sur mes fichiers car j'en télécharge un grand nombre et je ne référence que leur path. L'idéal serait donc de pouvoir, à la fermeture, indiquer que le fichier devra etre supprimé des que possible... (je rève ?)

**smyley** · 17/04/2008, 20h24

Envoyé par monstroplante

(je rève ?)

Oui

L'histoire du DeleteOnClose ne fonctionne que par rapport au moment où sera fermé le handle.

Envoyé par monstroplante

Je ferais peut etre ca si je ne trouve pas de solution simple. Mais dans ce cas, je céeras un dossier au nom constant pour pouvoir supprimer les fichiers résiduels lors de la prochaine éxécution du programme.

Vu comme ça cette solution me semble moins affreuse

. Ma solution pour supprimer les fichiers temporaires c'est de lancer deux applications, l'application principale et une autre qui sera chargée de la suppression. Au fur et à mesure de la création des fichiers temps, l'application principale rajoute ceux cis dans un fichier ini qui liste tous les fichiers crées. Lorsque cette application se termine, le deleter qui surveillait le processId remarque que le programme s'est terminé et vide tout (avant de se supprimer lui même,, mais ça c'est plus vis à vis de l'utilisation que j'en fait ...)

**monstroplante** · 17/04/2008, 22h27

Intéressant ta solution ! C'est une méthode classique ou une pure invention de ta part ?
Pour le moment je vais me contenter de la solution pas idéale décrite dans mon précédent post. Mais je garde la tienne dans un coin de ma tête pour plus tard...

Pour ceux que ça intéresse, voici le code de ma classe "FileHelper" qui prend en charge la gestion de mes fichiers temporaires :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
 
	static class FileHelper {
		private static string _tempFolder;
		private const string TEMP_SUBFOLDER_NAME = "CoverFinder_Tem_Folder";
		public static string TempFolder{
			get {
				if (_tempFolder == null) {
					_tempFolder = Path.Combine(Path.GetTempPath(), TEMP_SUBFOLDER_NAME);
					Directory.CreateDirectory(_tempFolder);
					Application.Current.Exit += new ExitEventHandler(Application_Exit);
				}
				return _tempFolder;
			}
		}
 
		public static string GetTempFileName() {
			return GetTempFileName(null);
		}
 
		public static string GetTempFileName(string extention) {
			if (extention == null) {
				extention = "";
			} else {
				if (extention.Length > 1) {
					//todo : check with Path.GetInvalidFileNameChars
					if (!extention.StartsWith("."))
						extention = '.' + extention;
				}
			}
			return Path.Combine(TempFolder, Guid.NewGuid().ToString() + extention);
		}
 
		/// <summary>
		/// Supprime le dossier temporaire à la fermeture de l'application
		/// </summary>
		/// <remarks>Les fichier ne pouvant etre supprimés le serons lors de la prochaine execution...</remarks>
		/// <param name="sender"></param>
		/// <param name="e"></param>
		static void Application_Exit(object sender, ExitEventArgs e) {
			foreach (string f in Directory.GetFiles(_tempFolder,"*",SearchOption.AllDirectories)) {
				try {
					File.Delete(f);
				} catch {}
			}
			foreach (string f in Directory.GetDirectories(_tempFolder,"*",SearchOption.TopDirectoryOnly)) {
				try {
					Directory.Delete(f,true);
				} catch { }
			}
		}
	}

Je concidère mon problème comme résolu mais si qqun à une solution à proposer, faut pas hésiter

En tout cas, merci beaucoup pour votre aide !

**smyley** · 17/04/2008, 22h35

Envoyé par monstroplante

Intéressant ta solution ! C'est une méthode classique ou une pure invention de ta part ?

Peut être que ça existait déjà, mais je l'ai trouvé tout seul au bout d'un mois de bugs bizarres où les fichiers n'étaient pas supprimés

**Greybird** · 18/04/2008, 07h41

Envoyé par smyley

Oui

L'histoire du DeleteOnClose ne fonctionne que par rapport au moment où sera fermé le handle.

Vu comme ça cette solution me semble moins affreuse

. Ma solution pour supprimer les fichiers temporaires c'est de lancer deux applications, l'application principale et une autre qui sera chargée de la suppression. Au fur et à mesure de la création des fichiers temps, l'application principale rajoute ceux cis dans un fichier ini qui liste tous les fichiers crées. Lorsque cette application se termine, le deleter qui surveillait le processId remarque que le programme s'est terminé et vide tout (avant de se supprimer lui même,, mais ça c'est plus vis à vis de l'utilisation que j'en fait ...)

Alors là c'est moi qui trouve ça affreux... Utiliser deux applications, dont une surveille l'autre pour juste éviter de laisser quelques fichiers dans le répertoire temporaire, c'est de l'overkill. Un watchdog, on s'en sert pour des problématiques de surveillance d'une application critique, pas pour ça, et encore moins pour une application cliente (sauf cas exceptionnels).

Et puis soyons serieux, comment vas-tu gérer les reboot brutaux/coupures de courant dans ce cas ? Tu surveilles la présence de courant électrique du pc du client grâce à un équipement que tu lui as fourni, qui appelle un call center qui dépêche un gars sur place pour allez supprimer les fichiers du répertoire temporaire ?
Ah j'oubliais, il faut aussi surveiller cet équipement, si des fois il tombait en panne ...

Encore une fois, le répertoire temporaire est là pour accueillir des élements qui ont vocation à disparaître un jour, quand on aura besoin de place sur le disque. Cela n'empêche pas de faire un peu de ménage derrière soi, mais déployer des usines à gaz pour supprimer au plus tôt 3 fichiers que Windows proposera de supprimer de lui-même dès que le besoin de place sur le disque se fera sentir... (Ca ne vous rappelle pas le Garbage Collector d'ailleurs ?) Il vaut mieux passer du temps à l'ajout de fonctionnalités au soft qu'à ce genre de problèmes qui n'en sont pas...

Quand aux BackgroundWorker, ils supportent bien l'annulation. Il faut mettre la propriété WorkerSupportsCancellation à true, et via la méthode CancelAsync(), on peut demander l'arrêt. Cela suppose de tester régulièrement la propriété CancellationPending dans la boucle de traitement.

**smyley** · 18/04/2008, 07h58

Envoyé par Greybird

Alors là c'est moi qui trouve ça affreux... Utiliser deux applications, dont une surveille l'autre pour juste éviter de laisser quelques fichiers dans le répertoire temporaire, c'est de l'overkill. Un watchdog, on s'en sert pour des problématiques de surveillance d'une application critique, pas pour ça, et encore moins pour une application cliente (sauf cas exceptionnels).

L'application en question est un installeur, je ne peut pas me permettre de laisser des fichiers temporaires, car la somme de leur taille peut en théorie dépasser plusieurs centaines de Mo. Vu sa complexité en surveillant via une autre application je suis sur de supprimer les fichiers même si une erreur survient dans un des threads de l'installeur causant le crash de l'application, car le .NET Framework ne permet pas que l'on récupère d'un UnhandledException, quelque soit le thread sur lequel il survient.

Envoyé par Greybird

Et puis soyons serieux, comment vas-tu gérer les reboot brutaux/coupures de courant dans ce cas ? Tu surveilles la présence de courant électrique du pc du client grâce à un équipement que tu lui as fourni, qui appelle un call center qui dépêche un gars sur place pour allez supprimer les fichiers du répertoire temporaire ?
Ah j'oubliais, il faut aussi surveiller cet équipement, si des fois il tombait en panne ...

Les fichiers en questions sont rajoutés via DeleteOnReboot, et retiré une fois supprimés. Même si l'ordinateur redémarre, ils seront supprimés aux redémarrage de l'ordinateur, quelque soit ce qui c'est passé.

Envoyé par Greybird

Encore une fois, le répertoire temporaire est là pour accueillir des élements qui ont vocation à disparaître un jour, quand on aura besoin de place sur le disque. Cela n'empêche pas de faire un peu de ménage derrière soi, mais déployer des usines à gaz pour supprimer au plus tôt 3 fichiers que Windows proposera de supprimer de lui-même dès que le besoin de place sur le disque se fera sentir... (Ca ne vous rappelle pas le Garbage Collector d'ailleurs ?) Il vaut mieux passer du temps à l'ajout de fonctionnalités au soft qu'à ce genre de problèmes qui n'en sont pas...

Windows ne propose pas de supprimer les fichiers temporaires quand l'espace manque, il propose de nettoyer le disque de temps en temps. Une fois de plus mon programme est une usine à gaz qui peut nécéssiter la création de plusieurs centaines de Mo de fichiers temporraires. Il n'y a rien de plus sale qu'un installeur qui ne désinstalle pas tout ou qui laisse un chantier derrière lui.

**Greybird** · 18/04/2008, 08h10

Ton cas justifie sans doute l'utilisation de ta solution. Je te rapporte à mon évocation de "cas exceptionnels". Dans le cas d'un installeur, tu reconnaitras toi même que c'est très différent d'une application qui vit. Pour le besoin de suppression dans le répertoire temporaire d'une application déjà installée, et dans le cas qui nous concerne, je maintiens mes remarques, c'est de l'overkill.

Windows propose bien de faire le ménage quand l'espace disque manque, mais je te l'accorde, contrairement au GC ce n'est pas automatique, il faut une action de l'utilisateur quand il voit la notification.

**monstroplante** · 18/04/2008, 10h08

Du coup, j'en reste à ma solution qui, à l'usage, s'avère très simple et efficace.

Quand aux BackgroundWorker, ils supportent bien l'annulation. Il faut mettre la propriété WorkerSupportsCancellation à true, et via la méthode CancelAsync(), on peut demander l'arrêt. Cela suppose de tester régulièrement la propriété CancellationPending dans la boucle de traitement.

Oui, j'utilise cette fonctionalitée quand elle est appropriée. Je me cite :

actuellement j'utilise des BackGroundWorkers qui, à ma connaissance n'offre pas la possibilité de mettre fin brutalement au thread.

Quand j'écris "brutalement" je veux dire, mettre fin au trhead même si il est en train d'éxécuter un opération longue. Par exemple, si je télécharge un fichier en mode synchrone dans le thread de mon worker, je serais obligé d'attendre la fin du téléchargement pour prendre concience du CancellationPending...

**Greybird** · 18/04/2008, 11h01

Envoyé par monstroplante

Du coup, j'en reste à ma solution qui, à l'usage, s'avère très simple et efficace.

Oui, j'utilise cette fonctionalitée quand elle est appropriée. Je me cite :

Quand j'écris "brutalement" je veux dire, mettre fin au trhead même si il est en train d'éxécuter un opération longue. Par exemple, si je télécharge un fichier en mode synchrone dans le thread de mon worker, je serais obligé d'attendre la fin du téléchargement pour prendre concience du CancellationPending...

Effectivement, désolé j'ai visiblement beaucoup de mal à lire correctement tes phrases

.
Peut-être peux-tu télécharger le fichier en mode asynchrone, et si ce mode asynchrone supporte l'annulation, ...

**monstroplante** · 18/04/2008, 11h22

Hé bien je ne sais pas si le webclient supporte l'annulation (j'imagine que oui) mais en tout cas, comme expliqué plus haut, je trouve le mode assynchrone tout pourri ! Bien sure, je pourrais utiliser le mode assynchrone dans un BackgroundWorker mais je trouve que ca commence à faire un peu lourd. En plus, comme dans le mode assynchrone, il résoud le nom DNS dans le thread courant, il suffit que cette opération prenne du temps pour que l'annulation soit impossible. Je pourrais aussi abandoner le BackgroundWorker et utiliser un simple Trheader puis gérer mo même la synchro avec le trhead de l'interface mais au final, ca fait pas mal de prise de tête pour pas grand chose. M'enfin je m'explique plus pour le "fun" qu'autre chose, j'ai maintenant, et grace à votre aide, une solution qui me convient

Bonne gestion des fichiers temporaires ?

C#

Discussions similaires

Partager

Partager